Accessibility
WAI
The Web Accessibility Initiative (WAI) by the W3C develops standards and support materials to help you understand and implement accessibility
.
It ensures that W3C standards support accessibility, and develops accessibility guidelines.
[w3.org, w3.org]
WCAG
The Web Content Accessibility Guidelines (WCAG) explain how to make web content more accessible to people with disabilities
. It provides guidelines and testable success criterias to determine WCAG conformance.
[w3.org]
- WCAG 2.1 (Recommendation)
- WCAG 2.2 (Recommendation)
- WCAG 3 (Draft)
ATAG
Authoring tools are software and services that 'authors' (web developers, designers, writers, etc.) use to produce web content (static web pages, dynamic web applications, etc.). [...]
Authoring Tool Accessibility Guidelines (ATAG) explains how to make the authoring tools themselves accessible, so that people with disabilities can create web content, and help authors create more accessible web content — specifically: enable, support, and promote the production of content that conforms to Web Content Accessibility Guidelines (WCAG).
[w3.org]
ACT
The Accessibility Conformance Testing Community Group (ACT) establishes and documents rules for testing the conformance of web content to accessibility standards, such as Web Content Accessibility Guidelines (WCAG). These test rules address automated, semi-automated, and manual testing. ACT makes accessibility testing more transparent, and thus reduces confusion caused by different interpretations of accessibility guidelines.
[w3.org]
- w3.org/WAI/standards-guidelines/act/rules/about
- w3.org/WAI/standards-guidelines/act/rules
- w3.org/TR/act-rules-format
- w3.org/WAI/standards-guidelines/act/implementations
- deque.com/blog/the-web-accessibility-interpretation-problem
Keyboard Navigation
Related: interaction
Resources:
- smashingmagazine.com/2022/11/guide-keyboard-accessibility-html-css-part1
- smashingmagazine.com/2022/11/guide-keyboard-accessibility-javascript-part2
- sarasoueidan.com/blog/focus-indicators
Hiding Content
By default, most elements are displayed to the user and also exposed to assistive technology.
To hide an element visually and also for assistive technology, use display: none
[MDN], visibility: hidden
[MDN] or the hidden
attribute [MDN].
Some elements should be displayed visually, but hidden for assistive technology. For example, a decorative icon that is displayed in addition to a descriptive text. For blind users, that icon does not provide any value.
You can hide such elements from assistive tech with aria-hidden="true"
[MDN].
But make sure to not use aria-hidden="true"
on focusable elements [scottohara.me].
Sometimes it is useful to visually hide certain elements but expose them to assistive technology.
There is currently no simple, native way to do that. But there are some CSS properties that—in combination—can be used instead.
Usually, a utility class is used to visually hide certain elements like that.
Such a class is often called .visually-hidden
[e.g. getbootstrap.com].
Visually hidden content should usually not contain any interactive (i.e. focusable) content. But it may contain interactive content if it should visually appear only when focused.
An example implementation to hide content visually could look as follows.
[tpgi.com,
scottohara.me,
a11yproject.com,
kittygiraudel.com,
webaim.org]
.visually-hidden:not(:focus):not(:focus-within):not(:active) {
position: absolute;
width: 1px;
height: 1px;
overflow: hidden;
clip: rect(0 0 0 0);
clip-path: inset(50%);
white-space: nowrap;
}
There are suggestions to add a native way to visually hide content to the web platform [benmyers.dev, w3c/csswg-drafts#560, whatwg/html#4623].
Live Regions
Live regions are areas that trigger screen readers to announce their content when it changes, e.g. notifications or form errors.
- developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions
- w3.org/TR/wai-aria-1.2/#dfn-live-region
- scottohara.me/blog/2022/02/05/are-we-live.html
- htmhell.dev/adventcalendar/2023/22
- github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/AriaNotify/explainer.md
Case Studies
People with low vision may use (multiple) tooling and/or custom configurations to make websites usable for them. That may include screen readers, screen magnification, increasing browser zoom levels, setting browser default text sizes, and/or others. [webaim.org]. Zooming levels of visually impaired people may be larger than 800% [webaim.org]. Those with significant vision loss may be more likely to use the keyboard for navigation [webaim.org].