- Understand and interpret WCAG 2.2
- Be familiar with WCAG 2.2 Success Criteria
- Understand the relationship between principles, guidelines, and success criteria.
- Understand the intent, requirements, and impact of each principle, guideline, and success criterion.
- Be familiar with Sufficient Techniques, Failure, and Advisory Techniques for each
success criterion.
- Understand the conformance level designations (A, AA, AAA).
- Identify the conformance level of each WCAG 2.2 success criterion.
- Understand the three types of techniques and the W3C vetting process for
techniques.
- Understand the difference between normative and non-normative information in
WCAG 2.2.
- Understand and interpret WAI-ARIA 1.2
- Understand the purpose and impact of WAI-ARIA 1.2.
- Understand the WAI-ARIA 1.2 model of roles and properties.
- Know when and why to use WAI-ARIA 1.2, and when to use standard HTML instead.
- Understand and interpret ATAG 2.0
- Understand how ATAG 2.0 applies to web content authoring tools.
- Understand the meaning and intent of the two main sections of ATAG 2.0.
- Understand the intent, requirements, and impact of each principle, guideline, and success criterion.
- Distinguish between good, automated practices in authoring tools and good
practices that require author/user input.
- Understand the power and limitations of automated accessibility authoring
features.
- Understand the difference between normative and non-normative information in
ATAG 2.0.
- Understand and interpret EN 301 549
- Know what kind of technologies are addressed by EN 301 549
- Identify the similarities and differences between WCAG and EN 301 549
- Describe how WCAG is represented in EN 301 549
- Identify requirements beyond WCAG that are relevant for compliance with the Web
Accessibility Directive 2016/2102.
- Understand the intent and scope of requirements in Annex A Table A1 that go
beyond WCAG.
- Create accessible interfaces with Javascript
- Understand the concept of progressive enhancement.
- Understand how JavaScript can improve or damage accessibility and user
experience depending on its use.
- Describe the impact of device-independent event handlers on accessibility.
- Understand the impact of an onClick()event applied to a native <a> or
<button> element in contrast to applying it to a non-semantic element, such as a
generic <div>.
- Be familiar with the user’s expectations regarding focus movement.
- Know when and how to send focus to new content using JavaScript.
- Understand the methods that can be used to notify screen readers that new
content has been added dynamically.
- Be familiar with the 5 rules for using ARIA.
- Understand the importance of coding to standards, rather than to the quirks or
features of only one set of technologies.
- Know about the semantic structure of the roles. Some roles require parent or child
roles, and some roles require attributes.
- Be familiar with techniques for providing accessible names and descriptions.
- Be familiar with the authoring practices for custom widgets, including semantic
structure, keyboard behavior, etc.
- Be familiar with the keyboard interaction model for ARIA custom widgets. There are
general keyboard patterns and patterns specific to certain types of widgets.
- Understand the importance of testing web designs for accessibility across a variety
of platforms, browsers, and assistive technologies. Do not just assume they will
work, even if they technically conform to published accessibility specifications.
- Know how to determine when an inaccessible outcome is the result of flaws in the
design versus poor support of the technology.
- Know when it may be appropriate to write code that overrides, supplements, or
fixes bugs in browsers or assistive technologies (do this only with great care).
- Understand and interpret WAI-ARIA 1.2
- Understand the purpose and impact of WAI-ARIA 1.2.
- Understand the WAI-ARIA 1.2 model of roles and properties.
- Know when and why to use WAI-ARIA 1.2, and when to use standard HTML
instead.
- Study how assistive technologies interact with user agents(browsers, apps).
- Understand differences in AT behavior across platforms and devices.
- Learn how touch interactions change with screen readers (e.g., gestures on mobile
with VoiceOver).
- Understand the role of ARIA in enhancing AT support for dynamic content.
- Become familiar with the keyboard interaction model for ARIA custom widgets. There are general keyboard patterns, plus keyboard patterns specific to types of widgets.
- In many widgets, the keyboard interaction model is to tab to the widget as a whole,
or the active/selected element within the widget, then use the arrow keys to
navigate within the widget. The tab key is generally not used for navigation within
the widget. Other keystrokes may be recommended for certain widgets.
- Native HTML widgets should be used instead of custom WAI-ARIA widgets
whenever possible, because of the built-in accessibility features of native HTML
widgets. Implementing custom widgets requires greater attention to detail in the
coding techniques and patterns, and support for custom widgets may vary,
especially for less common widgets.
- When creating ARIA widgets, pay attention to the semantic structure of the roles.
Some roles have required parent or child roles, and some roles have required
attributes.
- When a custom role is assigned to an element, the custom role completely
overrides the native role. For example, <li role=”button”> will be treated as
a button by the accessibility API, not like a list item.
- Roles to describe the type of widget presented, such as “menu”, “treeitem”,
“slider”, and “progressbar”.
- Roles to describe the structure of the Web page that include headings, regions, and tables.
- Properties to describe the state widgets are in, such as “checked” for a checkbox, or
“expanded” for a menu.
- Properties to define live regions of a page that are likely to get updates (such as
stock quotes), as well as an interruption policy for those updates—for example,
critical updates may be indicated in an alert dialog box, and incidental updates
occur within the page.
- In the case of complex web applications or dynamic contents, ARIA roles, states,
and properties may be used that communicate to the screen reader with what is
occurring in the interface.
- The application role should be used sparingly, if at all, because it overrides many
assistive technology keystrokes, such as the keystrokes that allow screen reader
users to navigate by semantic elements such as headings, landmarks, tables, etc.
- If the AJAX content is loaded as the direct result of a user action (e.g., activating a
button), the screen reader user should be notified that new content has loaded.
Methods that can be used to notify screen readers that new content has loaded
include:
- Sending the focus to the new content
- Using aria-live to announce content without moving the focus (e.g., providing a
status message, such as “New Page: [Name of new page])
- Update the page title via JavaScript (document.title)
- If the AJAX content is loaded passively (i.e., not as the direct result of a user action like activating a button), users may not need to be notified that the new content
has loaded. This action may be dependent on the importance and urgency of the
new content, and whether the content has been inserted above the user’s current
position or not.
- Understand the accessible design principles and how they relate to user needs.
- Define the terms “assistive technology” and “adaptive strategies”.
- List different types of assistive technologies and adaptive strategies.
- List types of disabilities and related accessibility needs.
- Understand the impact of design decisions on accessibility for people.
- Be familiar with different types of assistive technologies and how they work.
- Identify most common screen readers and recommended combinations to ensure
better compatibility.
- Be familiar with navigation strategies using a screen reader.
- Understand the modes of interaction across screen readers and their impact on
browsing with the assistive technology.
- Know the consequences of using contrast enhancement modes such as Windows
High Contrast Mode.