initial commit

.gitignore

@@ -0,0 +1,69 @@
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (http://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+# Typescript v1 declaration files
+typings/
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# dotenv environment variables file
+.env
+
+# gatsby files
+.cache/
+public
+
+# Mac files
+.DS_Store
+
+# Yarn
+yarn-error.log
+.pnp/
+.pnp.js
+# Yarn Integrity file
+.yarn-integrity

LICENSE

@@ -0,0 +1,22 @@
+The MIT License (MIT)
+
+Copyright (c) 2015 gatsbyjs
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+

README.md

@@ -0,0 +1,51 @@
+# Accessibility in JavaScript Applications
+
+Learn the necessary techniques and tools for building inclusive web applications with JavaScript from Gatsby's Head of Learning Marcy Sutton.
+
+Presented at:
+- [Frontend Masters](https://frontendmasters.com/workshops/javascript-accessibility/)
+
+Some key takeaways:
+
+- Understand how to incorporate accessibility into your web development workflow.
+- Debug your sites and applications for accessibility using the latest tools.
+- Apply accessibility to React web applications with Gatsby, while learning how accessibility applies to other stacks.
+- Learn the benefits of manual and automated testing to grow web accessibility superpowers!
+- Integrate focus management into your web applications, gracefully handling keyboard and screen reader interactions.
+- Practice announcing view changes with your code and keeping screen reader users up to date.
+- Achieve wins with semantic markup, unobtrusive animation, and progressive enhancement.
+
+Site URL: https://marcysutton.github.io/js-a11y-workshop
+
+Slides: https://marcysutton.github.io/js-a11y-workshop/slides/
+
+---
+
+This project was started with [gatsby-starter-mdx-basic](https://github.com/christopherbiscardi/gatsby-starter-mdx-basic) and [@mdx-deck/theme](https://github.com/jxnblk/mdx-deck/tree/master/packages/gatsby-theme).
+
+1. Create a new Gatsby site and slide deck using this starter
+
+```sh
+gatsby new my-site https://github.com/marcysutton/js-a11y-workshop
+```
+
+2. Install dependencies
+
+```sh
+npm install
+```
+
+3. Run the develop script
+
+```sh
+npm start
+```
+
+View in a browser: http://localhost:8000!
+
+4. Edit slide content in `src/slides/*`
+
+5. Edit site pages in `src/pages/*`
+
+6. Edit site components in `src/components/*`
+

gatsby-config.js

@@ -0,0 +1,64 @@
+const path = require('path')
+
+module.exports = {
+  siteMetadata: {
+    title: `Accessibility in JavaScript Applications`,
+    description:
+      `Learn the necessary techniques and tools for building inclusive web applications with JavaScript.`,
+    author: `@marcysutton`,
+  },
+  __experimentalThemes: [
+    {
+      resolve: `@mdx-deck/gatsby-theme`,
+      options: {
+        // disable gatsby-mdx plugin – use this when your site already uses gatsby-mdx
+        mdx: false,
+        // source directory for decks
+        path: `src/slides`,
+        // name routes' basepath
+        name: `slides`,
+      },
+    },
+  ],
+  plugins: [
+    `gatsby-plugin-sass`,
+    {
+      resolve: `gatsby-mdx`,
+      options: {
+        defaultLayouts: { default: path.resolve(`./src/components/layout.js`) },
+      },
+    },
+    `gatsby-plugin-react-helmet`,
+    {
+      resolve: `gatsby-source-filesystem`,
+      options: {
+        name: `images`,
+        path: `${__dirname}/src/images`,
+      },
+    },
+    {
+      resolve: `gatsby-source-filesystem`,
+      options: {
+        name: `pages`,
+        path: `${__dirname}/src/pages`
+      }
+    },
+    `gatsby-transformer-sharp`,
+    `gatsby-plugin-sharp`,
+    {
+      resolve: `gatsby-plugin-manifest`,
+      options: {
+        name: `js-a11y-workshop`,
+        short_name: `jsa11y`,
+        start_url: `/`,
+        background_color: `#663399`,
+        theme_color: `#663399`,
+        display: `minimal-ui`,
+        icon: `src/images/blueicon.png`, // This path is relative to the root of the site.
+      },
+    },
+    // this (optional) plugin enables Progressive Web App + Offline functionality
+    // To learn more, visit: https://gatsby.app/offline
+    // `gatsby-plugin-offline`,
+  ],
+}

outline.yml

@@ -0,0 +1,87 @@
+
+Outline:
+    - Introduction
+      - Who is Marcy Sutton?
+      - Overview of what we’ll cover
+      - Examples of inaccessible web applications: show the pain
+      - Examples of better web applications
+        - Built HTML pages in Gatsby
+    - Install demos and tools
+      - Get people downloading the Gatsby demo app and NVDA if on Windows
+        - Gatsby Demo app
+          - Make sure everyone can install it and run the tests
+          - Do a quick tour of the source code
+        - Browser extensions / common testing tools
+    - Accessibility debugging: using some of the intro examples
+      - Rendering code in a browser for basic accessibility testing (quick explanation of web context / DOM vs. Node.js tooling)
+        - Prototyping: budo
+        - Gatsby demo app: starting a server with a bigger project
+        - Discuss other rendering/localhost options, like http-server and Vue/Angular-specific things
+      - Using the TAB key to check for keyboard support.
+        - Apple OS setting (a common gotcha)
+        - Visible focus outlines
+        - What shouldn’t be interactive/operable with TAB?
+        - EXERCISE: TAB through some webpages. Can you see where you are on the screen? Can you reach everything?
+        - Known patterns / ARIA Authoring Practices Guide
+          - Promote user testing with people with disabilities early and often
+      - Chrome devtools color contrast debugger
+      - Testing with the axe browser extensions for Chrome and Firefox
+        - EXERCISE: Run an extension on a site
+      - Screen reader testing overview
+        - Recommended combinations: Voiceover and Safari, NVDA and Firefox, JAWS and IE11, iOS Safari + Voiceover, Android Firefox + Talkback, Narrator and Edge
+        - Provide resources to learn more (cheat-sheets, training, etc.)
+        - EXERCISE: use a screen reader (Mac Voiceover, iOS or Android, NVDA or Narrator for Windows)
+    - Introduction to accessibility in JavaScript applications
+      - Myth busting: accessibility + JavaScript can be BFFs.
+      - Focus management requirements + patterns
+        - Discuss focus manager APIs vs. components handling their own focus
+        - Tabindex=”-1” vs. tabindex=”0”
+        - React refs / other framework APIs
+        - Use cases:
+          - View changes
+          - Focus in new layers, replacing on close
+          - Disabling background layers
+          - Handling removal of DOM nodes
+        - Note known issues with iOS and other assistive technologies that can sometimes require workarounds (focus on buttons instead of headings, etc.)
+      - Announcements using ARIA Live Regions
+        - Use cases vary, there’s often more than one way to achieve something (discuss focus management vs. wrapping updating content in a live region, when you might not want to move focus, etc.)
+        - Talk about Live Region requirements: must be rendered on page, but can be visually hidden
+          - Sometimes two regions per “politeness” level are necessary to get everything to announce
+          - A site-level announcement API might be the way to go
+        - Async save / update / etc.
+        - Title changes
+        - Combobox usage / list filtering
+      - Semantic HTML
+        - Using semantics with JSX; verifying output
+        - Putting landmarks into your app
+      - Unintrusive Animation + prefers-reduced-motion
+        - toggle button
+        - OS-level setting
+      - Progressive enhancement: accessible baselines, fallbacks, challenges with JS frameworks
+    - Accessibility units: component-level API concerns
+      - Automated unit testing approach
+        - Test in isolation
+        - Stub inputs/fixture data
+        - Often headless
+        - Fast changing of state
+      - React Component examples with failing tests: combobox.
+        - Accessible names (buttons, links, form controls)
+          - TIPS: don’t use “click here” for links, consider adding visible labels for buttons
+        - Keyboard interactions: escape key, arrow keys
+        - Toggling ARIA states
+        - EXERCISE: Choose a couple failing tests and make them pass
+        - SOLUTION: Fix them together
+      - Bonus info: configurable heading levels, passing in ARIA attributes with component DSLs (don’t make up ARIA attributes; use data attributes instead) etc.
+    - Accessible pages
+      - Integration/end-to-end testing approach
+        - Real-world browser testing
+        - Cypress vs. Selenium Webdriver
+        - Document/page-level accessibility rules: page title, HTML lang, color contrast, heading hierarchy
+        - Component interoperability
+        - Framework testing flexibility
+        - Accessibility testing APIs make more sense here as you can run an entire ruleset against each page
+      - Gatsby example with failing tests
+        - EXERCISE: Color contrast debugging with axe and Chrome devtools
+        - EXERCISE: Fix failing focus management tests (showing component interop)
+        - EXERCISE: get Cypress tests passing on a page
+      - Q&A