Skip to content

david-workshops/2024-react-alicante

BranchesTags

Repository files navigation

Welcome to the workkshop!

In this workshop, we will dive into the world of code accessibility by leveraging Copilot, GitHub's AI coding assistant. Led by David Jensenius and Alena Nikolaeva from GitHub Copilot team.

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. The definition is more nuanced than that, though. The Web is fundamentally designed to work for all people. However, poorly designed and inaccessible applications lead to broad-scale exclusion.

Who defines web accessibility?

World Wide Web Consortium (W3C) - Web Content Accessibility Guidelines (WCAG)

It’s important to note that the WCAG standards themselves are guidelines, not law. 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.

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 include:

  • Usage without vision
  • Usage with limited vision
  • Usage without perception of colour
  • 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

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. Setup

  1. Redeem the Copilot code, or feel free to give away your copy after the workshop to someone who would use it
  2. Go to https://gh.io/ra
  3. Click on the code button
  4. Select the Codespaces tab
  5. Click Create codespace on main
  6. Visual Studio Code should start up with all packages installed
  7. Select the build and run tab in Visual Studio Code
  8. Run either "Debug React Code in Chrome" or "Debug React Code in Firefox"

3. Determine accessibility status of the page

  1. Open the website
  2. Check how bad the situation is (easy automatic checker), Wave or Axe
  3. Open Web developer extension
  4. 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?
  1. 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
  2. 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 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.
  3. Check headings with HeadingsMap
  4. Check images descriptions with Web developer extension
  5. Color contrast of elements with VisBug

4. Heads-down fixing!

When it comes to 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) as a reference point. The WCAG is a shared standard for web content accessibility for individuals, organizations, and governments. Licensed under CC.

The reccomendations targets many, but not all level A and AA concerns and prompts 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
  • 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)
  • The audio in videos should be captioned. 1.2.2
  • Actions, descriptions, and other important non-audio content in videos should be described in captions or a separate audio track. (1.2.3)
  • 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
  • The visual presentation of the content matches what’s read out by a screen reader. (1.3.2)
  • Nothing is referred to just by its color, size, position, shape, and so on. 1.3.3
  • Color shouldn’t be the only thing used to convey meaning. 1.4.1
  • Auto playing audio that lasts more than 3 seconds can be turned down or stopped. 1.4.2

2. Operable: can people use the content?

  • You can get around using the keyboard alone. 2.1.1
  • 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)
  • Keyboard shortcuts should use modifier keys, like [ctrl], [command], or [alt]/[option], but you can turn them off. 2.1.4
  • Time limits should be avoided unless they’re able to be extended. 2.2.1
  • Automatically moving/animating content that lasts more than 5 seconds should be able to be stopped or hidden. 2.2.2
  • Nothing flashes, blinks, or flickers more than three times in one second. 2.3.1
  • ‘Skip links’ are available for keyboard users to jump past navigation. 2.4.1
  • Each page has a unique <title> that describes what’s on that page. 2.4.2
  • 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
  • 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
  • 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
  • Actions (like pressing a button) aren’t triggered on mouse-down; rather on mouse-up. 2.5.2
  • The visible text of a form field, button, or link matches the text in the underlying code. 2.5.3
  • There is no reliance on device motion, like shaking or tilting, to carry out an action. 2.5.4

3. Undestandable: can people understand the content?

  • There’s a lang attribute on the element that matches the language of the page. 3.1.1
  • Nothing unexpected changes when something on the page receives keyboard focus, like a  3.2.1
  • Nothing unexpected changes when: the value of a form field, like an option in a select, is chosen 3.2.2
  • 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
  • Error/validation messages should be communicated in text, and should provide suggestions to help the user successfully proceed. 3.3.1
  • 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
  • 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

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

🎉 Congratulations! All of the criterias a checked for level A!

If you need a little more....

Here is a quick guide to catch more errors

Hint 
Remove `tabindex` attribute values that aren't either `0` or `-1`. Elements that are inherently focusable, such as links or `button` elements, do not require a `tabindex`. Elements that are not inherently focusable should not have a `tabindex` applied to them outside of very specific use cases.
Hint People who are blind or who have low vision may be disoriented when focus is moved without their permission. Additionally, `autofocus` can be problematic for people with motor control disabilities, as it may create extra work for them to navigate out from the autofocused area and to other locations on the page/view.
Hint If you cannot, let the person using your site know the timeout exists ahead of time, and provide significant notice before the timer runs out.
Hint The `title` attribute has numerous issues, and should not be used if the information provided is important for all people to access. Acceptable use for the `title` attribute would be labeling an `iframe` element to indicate what content it contains.

Keyboard

It is important that your interface and content can be operated, and navigated by use of a keyboard. Some people cannot use a mouse or may be using other assistive technologies that may not allow for hovering or precise clicking.

  • Make sure there is a visible focus style for interactive elements that are navigated to via keyboard input (focus visible)

  • Check to see that keyboard focus order matches the visual layout (meaningful sequence)

Hint Can a person navigating with a keyboard or screen reader move around the page in a predictable way?
Hint Remove the ability to focus on elements that are not presently meant to be discoverable. This includes things like inactive drop-down menus, off-screen navigations, or modals.

Images

Hint `alt` attributes (alternative text) give a description of an image for people who may not be able to view it. When an `alt` attribute isn't present on an image, a screen reader may announce the image's file name and path instead. This fails to communicate the image’s content.
  • Make sure that decorative images use null alt (empty) attribute values.
Hint Null alt attributes are also sometimes known as empty alt attributes. They are made by including no information between the opening and closing quotes of an alt attribute. Decorative images do not communicate information that is required to understand the website's overall meaning.
  • Provide a text alternative for complex images such as charts, graphs, and maps (non-text content)
Hint Is there a plain text which lists points on the map or sections of a flowchart? Describe all visible information. This includes graph axes, data points and labels, and the overall point the graphic is communicating

Headings

Heading elements (h1, h2, h3, etc.) help break up the content of the page into related “chunks” of information. They are incredibly important for helping people who use assistive technology to understand the meaning of a page or view.

Hint Heading elements construct a document outline, and should not be used for purely visual design.
Hint The `h1` element should be used to communicate the high-level purpose of the page or view.
  • Heading elements should be written in a logical sequence
Hint The order of heading elements should descend, based on the “depth” of the content. For example, `h4` element should not appear on a page before the first `h3` element declaration. A tool such as [headingsMap](https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en) can help you evaluate this.

Controls and links

Controls are interactive elements such as links and buttons that let a person navigate to a destination or perform an action.

Hint Without a `href` attribute, the link will not be properly exposed to assistive technology. An example of this would be a link that uses an `onClick` event, in place of a href attribute.
  • Ensure that links are recognizable as links (use of color)
Hint Color alone is not sufficient to indicate the presence of a link. Underlines are a popular and commonly-understood way to communicate the presence of link content.
Hint Visible focus styles help people determine which interactive element has keyboard focus. This lets them know that they can perform actions like activating a button or navigating to a link's destination.
Hint Buttons are used to submit data or perform an on-screen action that does not shift keyboard focus. You can add `type="button"` to a button element to prevent the browser from attempting to submit form information when activated.
  • Provide a skip link and make sure that it is visible when focused (bypass blocks)
Hint ```html Skip to main content ``` A skip link can be used to provide quick access to the main content of a page or view. This allows a person to easily bypass globally repeated content such as a website's primary navigation, or persistent search widget.
Hint Ideally, avoid links that open in a new tab or window. If a link does, ensure the link's behavior will be communicated in a way that is apparent to all users. Doing this will help people understand what will happen before activating the link. While this technique is technically not required for compliance, it is an often-cited area of frustration for many different kinds of assistive technology users.

Forms

Forms allow people to enter information into a site for processing and manipulation.

Hint Use a `for`/`id` pairing to guarantee the highest level of browser/assistive technology support.
Hint Does your form contain multiple sections of related inputs? Use `fieldset` to group them, and `legend` to provide a label for what this section is for.
Hint [Providing a mechanism](https://www.w3.org/TR/html52/sec-forms.html#sec-autofill) to help people more quickly, easily, and accurately fill in form fields that ask for common information (for example, name, address, phone number)
  • Make sure that form input errors are displayed in the list above the form after submission (error identification)
Hint This provides a way for assistive technology users to quickly have a high-level understanding of what issues are present in the form. This is especially important for larger forms with many inputs. Make sure that each reported error also has a link to the corresponding field with invalid input.
Hint Techniques such as [using aria-describedby](https://developer.paciellogroup.com/blog/2018/09/describing-aria-describedby/) allow people who use assistive technology to more easily understand the difference between the input and the error message associated with it.

Media

Media includes content such as pre-recorded and live audio and video.

Hint Unexpected video and audio can be distracting and disruptive, especially for certain kinds of cognitive disability such as ADHD.
  • Check to see that all media can be paused (keyboard)
Hint Provide a global pause function on any media element. If the device has a keyboard, ensure that pressing the `Space key` can pause playback. Make sure you also don't interfere with the `Space key`'s ability to scroll the page/view when not focusing on a form control.

Animation

Content that moves, either on its own, or when triggered by a person activating a control

Hint Certain kinds of strobing or flashing animations will trigger seizures. Others may be distracting and disruptive, especially for certain kinds of cognitive disability such as ADHD.
Hint Background video can be distracting, especially if the content is placed over it.
Hint Remove animations when the “reduce motion” setting is activated. If animation is necessary to communicate meaning for a concept, slow its duration down.

Color contrast

Color contrast is how legible colors are when placed next to, and on top of each other

  • Level AA compliance requires a contrast ratio of 4.5:1 for normal-sized text, icons, borders for inputs, radio buttons, checkboxes, etc (contrast)
  • Check custom ::selection colors
Hint Is the color contrast you set in [your `::selection` CSS](https://developer.mozilla.org/en-US/docs/Web/CSS/::selection) declaration sufficient? Otherwise, someone may not be able to read it if they highlight it.

Mobile / Touch

  • Check that the site can be rotated to any orientation (orientation)
  • Remove horizontal scrolling (reflow)
Hint Requiring someone to scroll horizontally can be difficult for some, irritating for all
  • Ensure that button and link icons can be activated with ease (target size)
Hint It's good to make sure things like hamburger menus, social icons, gallery viewers, and other touch controls are usable by a wide range of hand and stylus sizes.
  • Ensure sufficient space between interactive items in order to provide a scroll area (Bypass blocks)
Hint Some people who experience motor control issues such as hand tremors may have a very difficult time scrolling past interactive items that feature zero spacing.

Good news

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. It's never been easier before.

This guide is awesome if you want to continue learning, visual checklists for all WCAG criteria in Codepen or you can ask Copilot to be your personal a11y assistant. Also design principles can be really helpful to collab in the team.

And remember:

CleanShot 2024-08-19 at 10 56 58@2x

About

No description, website, or topics provided.

Resources

Readme

License

MIT license
Activity
Custom properties

Stars

0 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

 
 
 

Contributors

Languages