Below is a full list of study tasks from the IAAP Web Accessibility Specialist Body of Knowledge (BoK) 2.3. To view just the study tasks from each domain, click the link preceding the domain specific list.

Domain 1 (40%)

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

Domain 2 (40%)

<aside> ⚠️

Study tasks from domain 2D and 2H are the exact same in the BoK. I have deduplicated the list already.

</aside>

• Understand the needs of users of different types of disabilities
• Identify issues for the methods, technologies or strategies used by people with disabilities
• Become familiar with the specifications (WCAG, WAI-ARIA, and ATAG), and know which Success Criteria apply to which conformance level.
• Understand the WCAG conformance requirements.
• Understand the evaluation process of the WCAG-EM methodology.
• Be able to distinguish between failures of accessibility criteria versus other bad accessibility practices that are not covered in the specifications.
• Identify Issues for Screen reader users
• Identify Issues for Users who use a keyboard or alternative input device
• Identify Issues for Users with Auditory Disabilities
• Identify Issues for Users with Low Vision
• Identify Issues for Users with Cognitive or Learning Disabilities
• Identify Issues for Touch Users
• Understand the purpose of ACT Rules.
• Know the strengths and limitations of automated testing tools.
• Differentiate between the kinds of accessibility issues that can be found with automated tools and issues that require manual testing.
• Understand how accessibility software tools can be used at various stages in the web development process (e.g., design/develop/test).
• Be familiar with the types of software tools available (site-wide scanning, server-based analysis, unit testing, integration testing, browser developer tools, browser add-ons, simulators, guided manual testing, etc.).
• Know how to use the keyboard and screen readers to navigate ARIA custom widgets.
• Be familiar with standard keystrokes for interaction with interactive elements in native HTML.
• Know how to use the browser's built in Development Tools to inspect source code.
• Understand how accessibility software tools can be used at various stages in the web development process (e.g., design/develop/test).
• Characterise and differentiate between the disciplines of Agile and Waterfall project management methodologies and compare the approaches each methodology would have for accessibility quality assurance.
• Demonstrate an understanding of the benefits of designing digital content with accessibility in mind as opposed to remediation.
• Characterise and differentiate between the disciplines of accessibility and user experience design and compare assumptions of each discipline.
• Understand how accessibility needs to be integrated into the entire product life cycle, including concept, requirements, design, prototyping, development, quality assurance (QA), user testing, support, and regression testing.
• Identify ways in which each person’s role in the product life cycle can include some aspect of accessibility.
• Know which combinations of assistive technologies work best with which browsers.
• Know how to use screen readers to navigate content via landmarks and headings, use forms, and read content, including data tables. Be aware that mechanisms often differ between desktop (mostly keyboard-based: tab and arrow keys) and mobile (often gesture-based).
• Be aware that users of AT often use their tools in very different ways. For example, while screen readers offer various navigation modes for expert users, many actual users do not know or use these modes.
• Understand the different screen reader modes for interacting with different types of page content (Windows screen reader: read/browse mode, forms mode, application mode, VoiceOver rotor, TalkBack menu).
• Be familiar with standard keystrokes for interaction with interactive elements in native HTML
• Be familiar with conventions for keyboard interaction within ARIA widgets.
• Know the limitations of your assistive technology knowledge. If you are not experienced, do not assume something is an error. It may be that you do not know how to use the assistive technology correctly. Output anomalies or gaps could indicate a partial lack of screen reader support or bugs.
• Demonstrate an understanding of user testing and compare it to accessibility testing.
• Understand the value of user testing by users with various types of disabilities.
• Consider the consequences of certain types of accessibility flaws. Some flaws are more critical than others.
• Demonstrate an understanding of the design’s usability versus accessibility and the conformance to accessibility specifications.
• Understand the value of user testing by users with a variety of types of disabilities.
• Think through the consequences of certain types of accessibility flaws. Some flaws are more damaging than others are.
• Consider the usability of the design, not just the accessibility or conformance to the specifications. For further information, go to: W3C’s Involving Users in Evaluating Web Accessibility.

Domain 3 (20%)