Published: 3 Oct 2024 ## Introduction ### Definition At the most basic level, accessibility ensures that everyone, regardless of ability, education level, and software they use can access your website or application. ### Who defines web accessibility? World Wide Web Consortium (W3C) - [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) (WCAG) It’s important to note that the WCAG standards themselves are guidelines, not laws. The W3C itself evaluates organisations based on these standards but doesn’t have the authority to enforce them. The Web Content Accessibility Guidelines (WCAG) 2.1 is a comprehensive standard for web accessibility. It is also currently the basis for legislation on web accessibility in many parts of the world. To keep the commitment active, and most importantly, to translate it into action, all team members need to know how they should contribute in [their own specific role](https://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown). ### For who? There is a wide range of disabilities, but accessibility aims to make sure that people can use the web no matter their abilities. It is important to consider and design for different types of use cases, some of them included but not limited to: - Usage without vision - Usage with limited vision - Usage without perception of color - Usage without hearing - Usage with limited hearing - Usage without the vocal capability - Usage without manipulation or strength - Usage with limited reach - Minimise photosensitive seizure triggers - Usage with limited cognition ## Workbook - step by step ### 1. Resources and tools - [ ] Install Chrome extensions like [Wave](https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh), [HeadingsMap](https://chromewebstore.google.com/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi) and [Axe](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd) Optional extensions and tools: - [ ] Install [Accessibility checker](https://chromewebstore.google.com/detail/ibm-equal-access-accessib/lkcagbfjnkomcinoddgooolagloogehp) - [ ] Install [Web developer extension](https://chromewebstore.google.com/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm?pli=1) - [ ] Install[VisBug extension](https://chromewebstore.google.com/detail/visbug/cdockenadnadldjbbgcallicgledbeoc?hl=en) - [ ] Install [taba11y extension](https://chromewebstore.google.com/detail/taba11y/aocppmckdocdjkphmofnklcjhdidgmga?pli=1) - [ ] Bring the laptop with access to [GitHub](https://github.com/) (each participant will get an invitation to an organization or a coupon for complimentary Copilot access). - [ ] Basic accessibility knowledge (not mandatory). - [ ] [VS Code](https://code.visualstudio.com/download) - [ ] Basic knowledge of [React](https://react.dev/) - [ ] Learn a little bit about [Storybook](https://storybook.js.org/), we will use it. - [ ] If you’re interested in automated tests, you can even [integrate axe with Cypress](https://github.com/component-driven/cypress-axe) - [ ] Have foundational prompt that will turn Copilot Chat into accessibility assistant handy: - [ ] Will will use [this tool to fix color contrast](https://colourcontrast.cc/?background=ffffff&foreground=33a1cc), so have it handy! ``` I need to learn about accessibility and need to write code that conforms with the WCAG 2.1 level A and AA success criteria defined at https://www.w3.org/TR/WCAG21/. I want you to be my accessibility coach, a subject-matter expert that makes me think and account for all accessibility requirements and usability enhancements. When you answer questions about accessibility please use reputable sources such as w3.org, webaim.org, developer.mozilla.org, and https://www.ibm.com/able/. When possible, please provide links and references for additional learning. When you suggest code please use semantic HTML, ensure it is operable using the keyboard, follow WCAG 2.1 sufficient techniques, and follow the ARIA Authoring Practices Guide and related design patterns. Do you understand these instructions? ``` ### 2. Determine accessibility status of the page manually 1. Open the website 2. Check how bad the situation is (easy [automatic checker](https://www.webaccessibility.com/)), [Wave](https://chromewebstore.google.com/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh) or [Axe](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd) 4. Open [Web developer extension](https://chromewebstore.google.com/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm?hl=es) 5. Disable all styles - [ ] Does the website work without CSS (in case it doesn’t load)? - [ ] Does the order of elements of your page make sense? - [ ] Are images and icons sized correctly? - [ ] Is your document well structured? 5. Rendering (blurred vision, contrast) use Chrome Dev Tools. A perfect example are links, they should have underlines to easily differentiate them from normal text. P.S. prefers-reduced-motion for animations, zooming, and panning can be problematic for people who have vestibular disorders 6. Use the keyboard `tab` key ➡️ Put your mouse away and tab through the page and see if you can use every single part of the site without a mouse/touch pad. - [ ] Are focus styles clearly visible? - [ ] Can you navigate between headings? - [ ] Is everything focusable that should be? - [ ] Are your buttons real < button > s? - [ ] Is the overall UX using a keyboard great? - [ ] Are you managing focus correctly? - [ ] Do you hide and show elements correctly? - [ ] Does visual order match DOM order? - [ ] Turn on Wave and check ARIA labels and others → Wave and → Axe - [ ] Zoom in out 200% to check how/if text is scaling correctly. 8. Check headings with HeadingsMap 9. Check images descriptions with [Web developer extension](https://chromewebstore.google.com/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm?hl=es) 10. Color contrast of elements with [VisBug](https://chromewebstore.google.com/detail/visbug/cdockenadnadldjbbgcallicgledbeoc?hl=en) ### 4. Heads-down fixing! Regarding the underlying HTML code, we’re in luck: it has already been designed, from the outset, to be inclusive. HTML is a toolkit for inclusion. Using the right elements for the job doesn’t just mean the few who use screen readers benefit, but keyboard accessibility comes out of the box. The guide provided for this workshop uses [The Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/) as a reference point. The WCAG is a shared standard for web content accessibility for individuals, organisations, and governments. [Licensed under CC](https://creativecommons.org/licenses/by-sa/4.0/). The recommendations target many, but not all level A and AA concerns and prompt you to check for covers a wide range of disability conditions. > [!NOTE] > Don't forget to ask Copilot how to fix these in your codebase! **Level A** #### 1. Perceivable: can people read the content? - [ ] Text alternatives: images should have descriptive (alt) text. [1.1.1](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content) - [ ] Any audio-only content should also be conveyed in text. Any video content with no audio track should also be described in text, but could also be described with audio. ([1.2.1](https://www.w3.org/WAI/WCAG22/Understanding/audio-only-and-video-only-prerecorded)) - [ ] The audio in videos should be captioned. [1.2.2](https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded) - [ ] Actions, descriptions, and other important non-audio content in videos should be described in captions or a separate audio track. ([1.2.3](https://www.w3.org/WAI/WCAG22/Understanding/audio-description-or-media-alternative-prerecorded)) - [ ] Information or relationships between content that is visual is also conveyed through the code, via HTML or ARIA (for example the for attribute on a form label, or aria-describedby on an input that has hint text). [1.3.1](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships) - [ ] The visual presentation of the content matches what’s read out by a screen reader. ([1.3.2](https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence)) - [ ] Nothing is referred to just by its color, size, position, shape, and so on. [1.3.3](https://www.w3.org/WAI/WCAG22/Understanding/sensory-characteristics) - [ ] Color shouldn’t be the only thing used to convey meaning. [1.4.1](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color) - [ ] Auto playing audio that lasts more than 3 seconds can be turned down or stopped. [1.4.2](https://www.w3.org/WAI/WCAG22/Understanding/audio-control) #### 2. Operable: can people use the content? - [ ] You can get around using the keyboard alone. [2.1.1](https://www.w3.org/WAI/WCAG22/Understanding/keyboard) - [ ] There shouldn’t be a situation where you enter a modal with the keyboard and can’t get back to where you were. ([2.1.2](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap)) - [ ] Keyboard shortcuts should use modifier keys, like [ctrl], [command], or [alt]/[option], but you can turn them off. [2.1.4](https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts) - [ ] Time limits should be avoided unless they’re able to be extended. [2.2.1](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable) - [ ] Automatically moving/animating content that lasts more than 5 seconds should be able to be stopped or hidden. [2.2.2](https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide) - [ ] Nothing flashes, blinks, or flickers more than three times in one second. [2.3.1](https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold) - [ ] ‘Skip links’ are available for keyboard users to jump past navigation. [2.4.1](https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks) - [ ] Each page has a unique <title> that describes what’s on that page. [2.4.2](https://www.w3.org/WAI/WCAG22/Understanding/page-titled) - [ ] When a keyboard user tabs through a page, the order goes from top to bottom and left to right, as you would read the page. [2.4.3](https://www.w3.org/WAI/WCAG22/Understanding/focus-order) - [ ] It is clear where a link will take you from either: the link text itself, the information in the sentence leading up to the link [2.4.4](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context) - [ ] All actions that are carried out using a gesture (swiping, pinching, and so on) or drawing, can also be done with a button or buttons. [2.5.1](https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures) - [ ] Actions (like pressing a button) aren’t triggered on mouse-down; rather on mouse-up. [2.5.2](https://www.w3.org/WAI/WCAG22/Understanding/pointer-cancellation) - [ ] The visible text of a form field, button, or link matches the text in the underlying code. [2.5.3](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name) - [ ] There is no reliance on device motion, like shaking or tilting, to carry out an action. [2.5.4](https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation) #### 3. Undestandable: can people understand the content? - [ ] There’s a lang attribute on the <html> element that matches the language of the page. [3.1.1](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page) - [ ] Nothing unexpected changes when something on the page receives keyboard focus, like a <button> [3.2.1](https://www.w3.org/WAI/WCAG22/Understanding/on-focus) - [ ] Nothing unexpected changes when: the value of a form field, like an option in a select, is chosen [3.2.2](https://www.w3.org/WAI/WCAG22/Understanding/on-input) - [ ] Some form of help is available from every page, whether contact details, a contact form, a link to a contact page, or a link to help documentation. [3.2.6](https://www.w3.org/WAI/WCAG22/Understanding/consistent-help) - [ ] Error/validation messages should be communicated in text, and should provide suggestions to help the user successfully proceed. [3.3.1](https://www.w3.org/WAI/WCAG22/Understanding/error-identification) - [ ] As much help as is needed is offered to prevent triggering a form error; the form label may be enough, but hint text may also be required. [3.3.2](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions) - [ ] If the user as already given some information, it’s either: not asked for again, pre-populated in the subsequent field available to select in a dropdown [3.3.7](https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry) #### 4. Robust: can people operate for any device? - [ ] The semantic meaning of every interactive element (form controls, links, headings, landmarks, tables, and so on) is correct, and each has an accessible name. [4.1.2](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value) <hr> ### 🎉 Congratulations! We've covered some basics. <hr> ### If you need a little more.... <hr> Accessibility can never be perfect, but by thinking inclusively from planning, through prototyping to coding, you can reduce the time you spend on coding to minutes. [This guide is awesome if you want to continue learning](https://www.accessibility-developer-guide.com/introduction/), visual checklists for all [WCAG criteria in Codepen](https://codepen.io/weboverhauls/full/zYvopYE) or [you can ask Copilot](https://github.blog/developer-skills/github/prompting-github-copilot-chat-to-become-your-personal-ai-assistant-for-accessibility/) to be your personal a11y assistant. Also [design principles](https://inclusivedesignprinciples.info/) can be really helpful to collab in the team. And remember: