Problem
Our application is unusable for a large portion of the population.
Excluding people in this way contradicts our mission, propagates as ableism in our customers, and betrays a misuse of web technology.
Who is affected?
Real people. There are people who use us, but who cannot complete critical workflows because of their disabilities.
uhhhh more to come here
Accessibility in practice
Making web content accessible is easier than you'd expect.
Alternatives for non-text content
Non-text content, like images, videos, audio recordings, and charts, need to have text-based alternatives.
For some types of content, this means that the text must contain all of the information in the non-text content. For others, where a thorough description is impossible, a summary suffices.
Example: Adding alt text to images
alt text is the first thing most people picture when they
think about accessibility. It must be written with care, taking into
consideration the context of the photo. The W3C provides an
alt decision tree
to help determine how to write alt text (or when not to).
In the before example below, a screen reader reads the file name of the image. In the after example, a human has taken care to provide alt text, so the screen reader describes the contents of the image.
Before
After
WCAG 2.1 Compliance
This exemplifies the following WCAG 2.1 Success Criteria:
Example: Presentational content
Lots of elements of a UI do not need text alternatives. For example, button icons where the icon does not add information the text does not already provide:
Before
After
It is unhelpful for a screen reader to announce "right arrow" when the
meaning of the button is conveyed by its text. Marking the icon with
aria-hidden="true" prevents it from being announced.
Keyboard perceivability
Interactions that are possible via the mouse must also be possible via the keyboard. This means users must be able to see which elements are focused.
Example: Focus styles
Use the tab and shift tab keys to navigate these elements. Note that in the before, it's impossible to tell where you are. In the after, it's clear.
WCAG 2.1 Compliance
This exemplifies the following WCAG 2.1 Success Criteria:
Keyboard operability
Interactions that are possible via the mouse must also be possible via the keyboard. This means users must be able to interact with focused elements using the keyboard.
Example
Use your mouse to interact with these menus. Now, use your keyboard. Note the awkwardness of the before menu, where pressing things like enter and space "work" but do not feel native.
In the after menu, focus is managed and arrow keys are respected according to standards. Pressing escape closes the menu and restores focus to the button.
Before
After
WCAG 2.1 Compliance
This exemplifies the following WCAG 2.1 Success Criteria:
WAI-ARIA Authoring Practices 1.1 Compliance
This exemplifies the following WAI-ARIA 1.1 practices: