diff --git a/content/about/about.html b/content/about/about.html index 1c9e5cb61c..de6ded664c 100644 --- a/content/about/about.html +++ b/content/about/about.html @@ -15,285 +15,51 @@

About

- -
-

Introduction

-

- The ARIA Authoring Practices Guide (APG) explains how to create accessible web experiences for users of assistive technologies and keyboard interfaces by developing web sites that properly convey accessibility semantics and implement common keyboard conventions. - It also provides guidance on some closely related topics, such as supporting operating system settings for high contrast and reduced motion. -

-

- Accessibility semantics refer to the meaning of user interface elements that need to be conveyed to assistive technology users in order for those users to understand and use the elements. - For example, people who can visually perceive a search icon button understand the element can be activated to perform a search by the way it is styled and positioned. - To make that icon accessible to a screen reader user, one of the semantics that needs to be communicated is that the element represents an interactive button. - In addition, keyboard accessibility requires the button to be focusable, and keyboard conventions call for pressing Enter or Space to activate the button when it is focused. - The APG describes how to convey accessibility semantics and implement keyboard accessibility for many common design patterns, ranging from typical buttons and popup menus to complex tree grids. - It also explains essential practices related to these patterns, such as how to convey web page structure with ARIA landmark regions and effectively utilize the many ways of encoding accessible names. -

-

- The APG is organized into two major sections: patterns and practices. - Each pattern explains how to make a common user interface element, such as a button, menu, or dialog, accessible, and provides functional example implementations of the pattern. - The practices section gives in-depth explanation of how to satisfy a variety of accessibility needs that surface when making rich internet application experiences accessible. - For instance, the practices section on providing accessible names and descriptions gives detailed descriptions of seven different naming techniques as well as a table providing guidance for naming more than 80 types of elements. -

-

- The APG assumes basic understanding of web development, especially of HTML and CSS. - It may be particularly useful to designers and engineers who are working on site design systems and component libraries. - However, it is important to understand that the APG only covers a portion of what is needed to create accessible experiences. - To understand accessibility more broadly, it is advisable to start with the WAI Accessibility Fundamentals and WAI Overview of Design and Development. -

-

- The accessibility semantics used in the APG patterns and described in APG practices are defined in the - WAI-ARIA 1.2 Specification. - That is, the ARIA specification standardizes the meaning of the attributes that describe elements and their states to assistive technologies, such as the meaning of role="button". - These attributes and other features required to make sites usable by people who rely on assistive technologies or keyboard navigation are not natively included in the languages used to create web sites, such as HTML, JavaScript, CSS, and SVG. - The W3C Web Accessibility Initiative's (WAI) Accessible Rich Internet Applications working group (ARIA WG) is addressing these deficiencies through several W3C standards efforts. - The WAI-ARIA Overview - provides additional background on WAI-ARIA, summarizes those efforts, and lists the other documents included in the WAI-ARIA suite. -

-
- -
-

Change History

- -

- APG 1.1 supported ARIA 1.1, and this version, APG 1.2, includes changes to support version 1.2 of the ARIA specification. - It also includes nearly 200 significant updates to improve the quality and breadth of content. - A detailed log of all changes is available on the wiki of the w3c/aria-practices GitHub repository. - Highlights of major changes to support ARIA 1.2 as well as some of the improvements include the following. -

- -

Comprehensive lists of closed issues included in APG 1.2 release 1 are tracked in the following GitHub milestones.

- -
- -
-

Acknowledgements

-

Editors

-
-
Current editors:
-
- - (Facebook) -
-
- - (University of Illinois) -
-
- - (Adobe) -
-
- Zoë Bijl (Invited Expert) -
-
- Michael Cooper - (W3C) -
-
Former editors:
-
- Joseph Scheuhammer (Inclusive Design - Research Centre, OCAD University) - Until - -
-
- Lisa Pappas (SAS) - Until - -
-
- Rich Schwerdtfeger (IBM Corporation) - Until - -
-
- -
-

Honorary Editor

+
    +
  • +

    Introduction

    - This version of the ARIA Authoring Practices Guide is dedicated to the memory of Carolyn MacLeod whose contributions are visible throughout the entire guide. - She was dedicated to all aspects of the work of the APG Task Force from writing code and suggesting editorial revisions to testing examples with assistive technologies. + To learn about the purpose of the APG, the prerequisite knowledge it assumes, and how it is organized, read the + Introduction.

    -
      -
    • Carolyn MacLeod (IBM Canada)
      • -
    -
-
-

Major Contributors to Version 1.1

+ +
  • +

    ARIA Basics

    - While WAI-ARIA Authoring Practices 1.1 is the work of - the entire Authoring Practices Task Force and also benefits from many people throughout the open source - community who both contribute significant work and provide valuable feedback, special thanks goes to the - following people who provided distinctly large portions of the content and code in version 1.1. + Facilitate success when applying APG guidance by developing a solid understanding of what ARIA is, what accessibility semantics are, and their purpose and limitations with this section about + ARIA Basics.

    -
      -
    • Jon Gunderson and Nicholas Hoyt of the Division of Disability Resources and Education Services at the - University of Illinois Urbana/Champaign and the students Max Foltz, Sulaiman Sanaullah, Mark McCarthy, and - Jinyuan Zhou for their contributions to the development of many of the design pattern examples.
      • -
    • Valerie Young of Bocoup and her sponsor, Facebook, for development of the example test framework and - regressions tests for more than 50 examples.
      • -
    • Simon Pieters of Bocoup and his sponsor, Facebook, for authoring of significant guidance sections, - including comprehensive treatment of the topic of accessible names and descriptions.
      • -
    -
    • -
    -

    Participants active in the ARIA Authoring Practices Task Force

    -
      -
    • Ann Abbott (Invited Expert)
      • -
    • Shirisha Balusani (Microsoft Corporation)
      • -
    • Dorothy Bass (Wells Fargo Bank N.A.)
      • -
    • Curt Bellew (Oracle)
      • -
    • Zoë Bijl (Invited Expert)
      • -
    • - Michael Cooper (W3C) -
      • -
    • Bryan Garaventa (Level Access)
      • -
    • Jon Gunderson (University of Illinois at Urbana-Champaign)
      • -
    • Jesse Hausler(Salesforce)
      • -
    • Sarah Higley (Microsoft Corporation)
      • -
    • Hans Hillen (The Paciello Group, LLC)
      • -
    • Matt King (Facebook)
      • -
    • Jaeun Ku (University of Illinois at Urbana-Champaign)
      • -
    • Aaron Leventhal (Google)
      • -
    • Carolyn MacLeod (IBM Corporation)
      • -
    • Mark McCarthy (University of Illinois at Urbana-Champaign)
      • -
    • James Nurthen (Adobe)
      • -
    • Scott O'Hara (The Paciello Group, LLC)
      • -
    • Simon Pieters (Bocoup)
      • -
    • Scott Vinkle (Shopify)
      • -
    • Evan Yamanishi (W. W. Norton)
      • -
    • Valerie Young (Bocoup)
      • -
    -
    -
    -

    Other commenters and contributors to Version 1.1

    -
      -
    • Vyacheslav Aristov
      • -
    • J. Renée Beach
      • -
    • Kasper Christensen
      • -
    • Gerard K. Cohen
      • -
    • Anne-Gaelle Colom
      • -
    • Kevin Coughlin
      • -
    • Cameron Cundiff
      • -
    • Manish Dahamiwal
      • -
    • Gilmore Davidson
      • -
    • Boris Dušek
      • -
    • Michael Fairchild
      • -
    • Jeremy Felt
      • -
    • Rob Fentress
      • -
    • Geppy
      • -
    • Tatiana Iskandar
      • -
    • Patrick Lauke
      • -
    • Marek Lewandowski
      • -
    • Dan Matthew
      • -
    • Shane McCarron
      • -
    • Victor Meyer
      • -
    • Jonathan Neal
      • -
    • Philipp Rudloff
      • -
    • Joseph Scheuhammer
      • -
    • Nick Schonning
      • -
    • thomascorthals
      • -
    • Christopher Tryens
      • -
    -
    -
    - -
    -

    References

    -
    -

    Informative references

    -
    -
    [HTML]
    -
    - - HTML Standard - - . Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living - Standard. URL: - https://html.spec.whatwg.org/multipage/ -
    -
    [HTML-AAM]
    -
    - - HTML Accessibility API Mappings 1.0 - - . Steve Faulkner; Scott O'Hara. W3C. 26 October 2022. W3C Working Draft. URL: - https://www.w3.org/TR/html-aam-1.0/ -
    -
    [HTML-ARIA]
    -
    - - ARIA in HTML - - . Steve Faulkner; Scott O'Hara; Patrick Lauke. W3C. 27 September 2022. W3C Recommendation. URL: - https://www.w3.org/TR/html-aria/ -
    -
    [SVG2]
    -
    - - Scalable Vector Graphics (SVG) 2 - - . Amelia Bellamy-Royds; Bogdan Brinza; Chris Lilley; Dirk Schulze; David Storey; Eric Willigers. W3C. 4 - October 2018. W3C Candidate Recommendation. URL: - https://www.w3.org/TR/SVG2/ -
    -
    [WAI-ARIA]
    -
    - - Accessible Rich Internet Applications (WAI-ARIA) 1.1 - - . Joanmarie Diggs; Shane McCarron; Michael Cooper; Richard Schwerdtfeger; James Craig. W3C. 14 December 2017. - W3C Recommendation. URL: - https://www.w3.org/TR/wai-aria-1.1/ -
    -
    [WAI-ARIA-1.2]
    -
    - - Accessible Rich Internet Applications (WAI-ARIA) 1.2 - - . Joanmarie Diggs; James Nurthen; Michael Cooper. W3C. 8 December 2021. W3C Candidate Recommendation. URL: - https://www.w3.org/TR/wai-aria-1.2/ -
    -
    -
    -
    - + +
  • +

    Acknowledgements

    +

    + To learn about the people and organizations who contribute to the development of the APG, read the Acknowledgements. +

    +
    • +
  • +

    Change History

    +

    + A history of how the APG has changed, dating back to 2014, including easy access to the detailed commit log is available in the + Change History. +

    +
    • +
  • +

    Related Specifications

    +

    + The APG synthesizes guidance based on information from several specifications. + While the guidance contains contextual links to relevant specifications, it can be handy to have a consolidated list of all the + Related Specifications. +

    +
    • +
  • +

    Coverage and Quality Report

    +

    + Objectives of the APG Task Force include providing guidance or examples for all ARIA attributes and doing so with code that implements practices documented in the APG code guide. + As the APG is revised, the build process updates our view of Progress toward these objectives in the + Coverage and Quality Report. +

    +
    • +
    diff --git a/content/about/acknowledgements/acknowledgements.html b/content/about/acknowledgements/acknowledgements.html new file mode 100644 index 0000000000..30cc2a406a --- /dev/null +++ b/content/about/acknowledgements/acknowledgements.html @@ -0,0 +1,153 @@ + + + + + + Acknowledgements + + + + + + + + + +
    +

    Acknowledgements

    + +
    +

    Editors

    +
    +
    Current editors:
    +
    + + (Meta) +
    +
    + + (University of Illinois) +
    +
    + + (Adobe) +
    +
    + Zoë Bijl (Invited Expert) +
    +
    + Michael Cooper + (W3C) +
    +
    Former editors:
    +
    + Joseph Scheuhammer (Inclusive Design + Research Centre, OCAD University) - Until + +
    +
    + Lisa Pappas (SAS) - Until + +
    +
    + Rich Schwerdtfeger (IBM Corporation) - Until + +
    +
    +
    + +
    +

    Honorary Editor

    +

    + This version of the ARIA Authoring Practices Guide is dedicated to the memory of Carolyn MacLeod whose contributions are visible throughout the entire guide. + She was dedicated to all aspects of the work of the APG Task Force from writing code and suggesting editorial revisions to testing examples with assistive technologies. +

    + +
    + +
    +

    Major Contributors to Version 1.1

    +

    + While WAI-ARIA Authoring Practices 1.1 is the work of + the entire Authoring Practices Task Force and also benefits from many people throughout the open source + community who both contribute significant work and provide valuable feedback, special thanks goes to the + following people who provided distinctly large portions of the content and code in version 1.1. +

    + +
    + +
    +

    Participants active in the ARIA Authoring Practices Task Force

    + +
    + +
    +

    Other commenters and contributors to Version 1.1

    + +
    + +
    + + diff --git a/content/about/aria-basics/aria-basics.html b/content/about/aria-basics/aria-basics.html new file mode 100644 index 0000000000..ca215a9f80 --- /dev/null +++ b/content/about/aria-basics/aria-basics.html @@ -0,0 +1,59 @@ + + + + + + ARIA Basics + + + + + + + + + +
    +

    ARIA Basics

    +

    + A solid understanding of what ARIA is, what accessibility semantics are, and their purpose and limitations can facilitate success when applying guidance provided by the APG. +

    +
    +

    What is ARIA?

    +

    + ARIA, which stands for Accessible Rich Internet Applications, refers to a set of more than 150 declarations that can be added into web page code so assistive technologies, such as screen readers, can understand how to present the page. + For example, the text "Home" might be visually presented as a heading, an interactive link or button, or as the label for a phone number. + If the web code does not declare what the element containing that text represents, a screen reader cannot present it to a blind user in an accessible way. +

    +

    + The declarations that can be made with ARIA are defined by the WAI-ARIA Specification. + These attributes and other features required to make sites usable by people who rely on assistive technologies or keyboard navigation are not natively included in the languages used to create web sites, such as HTML, JavaScript, CSS, and SVG. + The W3C Web Accessibility Initiative's (WAI) Accessible Rich Internet Applications working group (ARIA WG) is addressing these deficiencies through several W3C standards efforts. + The WAI-ARIA Overview + provides additional background on WAI-ARIA, summarizes those efforts, and lists the other documents included in the WAI-ARIA suite. +

    +
    +
    +

    What Are Accessibility Semantics?

    +

    + Accessibility semantics refer to the meaning of user interface elements that need to be conveyed to assistive technology users in order for those users to understand and use the elements. + For example, people who can visually perceive a search icon button understand the element can be activated to perform a search by the way it is styled and positioned. + To make that icon accessible to a screen reader user, one of the semantics that needs to be communicated is that the element represents an interactive button. + This is accomplished by encoding the element in a way that enables browsers to determine that the accessibility role of the element is button. + Similarly, another accessibility semantic browsers must be able to convey for the search icon is its accessible name, which inturn enables screen reader users to know the purpose of the button. +

    +

    + The types of accessibility semantics that may be required to make an element accessible include: +

    + +
    +
    + + diff --git a/content/about/change-history/change-history.html b/content/about/change-history/change-history.html new file mode 100644 index 0000000000..4ef797750d --- /dev/null +++ b/content/about/change-history/change-history.html @@ -0,0 +1,66 @@ + + + + + + Change History + + + + + + + + + +
    +

    Change History

    +

    + APG 1.1 supported ARIA 1.1, and this version, APG 1.2, includes changes to support version 1.2 of the ARIA specification. + It also includes nearly 200 significant updates to improve the quality and breadth of content. + A detailed log of all changes is available on the wiki of the w3c/aria-practices GitHub repository. + Highlights of major changes to support ARIA 1.2 as well as some of the improvements include the following. +

    + +

    Comprehensive lists of closed issues included in APG 1.2 release 1 are tracked in the following GitHub milestones.

    + +
    + + \ No newline at end of file diff --git a/content/about/introduction/introduction.html b/content/about/introduction/introduction.html new file mode 100644 index 0000000000..0489ae91b0 --- /dev/null +++ b/content/about/introduction/introduction.html @@ -0,0 +1,185 @@ + + + + + + Introduction + + + + + + + + + +
    +

    Introduction

    +

    + This introduction to the ARIA Authoring Practices Guide (APG) describes the purpose of the APG, the prerequisite knowledge it assumes, and how it is organized. +

    + +
    +

    Purpose of the APG

    +

    + The APG synthesizes requirements from multiple accessibility and web technology specifications into guidance for developing web experiences for people who rely on assistive technologies and keyboard interfaces. + It includes a library of accessible user interface patterns, example implementations of the patterns, and guidance sections that explain how to: +

    + +

    + The primary aim of the APG is to increase the availability of robust accessible experiences by building broad understanding and encouraging adoption of web accessibility practices that: +

    + +
    + +
    +

    APG is Not a Normative Standard

    +

    + The accessibility guidance in the APG is different from accessibility requirements specified by WCAG and ARIA. + WCAG and ARIA are "W3C normative technical standards" while the APG is an "informative" resource. + W3C normative technical standards, which are formally known as "W3C Recommendations", have conformance models that define how to comply with the requirements documented in the standard. + Those requirements are developed using a rigorous process defined by + The W3C Recommendation Track. +

    +

    + The APG does not specify normative requirements and thus does not have a conformance model. + The ARIA Authoring Practices Task Force, which is part of the ARIA Working Group, + uses consensus to ensure APG guidance is consistent with all relevant specifications, including ARIA, but its process for doing so is not bound by the W3C Recommendation Track process. +

    +

    + Some of the guidance in the APG is not covered by a normative specification. + For example, the patterns include keyboard interaction models that combine a normative requirement specified by ARIA with conventions established by popular operating systems and software. + In the section on Managing focus, ARIA includes normative language stating that the Tab key should not move focus inside of certain types of widgets. + However, ARIA does not specify how specific keys should move focus inside of those widgets. + So, the APG Task Force relies on broadly utilized keyboard conventions to provide each pattern with a list of keyboard commands for navigation and operation. + While those lists are not normative, the majority of such conventions are so well established that it is advisable to treat them as requirements. + Where that is not the case, the guidance is clearly marked as optional. + Note that there are some keyboard commands where users could be better served if a web widget were to dynamically adjust to mirror the users' operating system conventions. + It is a known issue that some APG keyboard interaction models do not yet provide sufficient macOS-specific guidance.

    +
    + +
    +

    Exercise Caution If Deviating from APG Patterns

    +

    + While APG is not a standard, its patterns and practices do convey requirements from normative standards. + To help authors address a wide variety of UI design needs, the patterns and practices describe ranges of possibilities and options that satisfy those standards. + The examples each represent a specific way of implementing one or more patterns; they are intended to be illustrative, not prescriptive. +

    +

    + It is important to understand, however, that the APG pattern library is not intended to serve as a catalog of all possible, valid, and potentially usable ways of building accessible user interfaces. + Consequently, some developers may find it necessary to go beyond simply combining various APG patterns to create an experience that supports their UI requirements. + If building UI that deviates from APG patterns, ensure the design and behavior of the UI: +

    + +
    + +
    +

    APG is not a UI Design System

    +

    + While the APG includes a library of patterns and functional examples, it's objectives do not include providing a comprehensive design system or production-ready code. + Not only would developing a production-ready design system be beyond the capacity of the Authoring Practices Task Force, developing examples that satisfy requirements of a unified design system would inhibit its primary aim of building broad understanding of relevant practices. + APG examples, including code style, are designed to facilitate learning the accessibility concepts they illustrate. + To show how different approaches to design can satisfy accessibility requirements, the styles and behaviors of examples are sometimes intentionally inconsistent from one another. + Additionally, the examples are intended to be reasonably realistic and utilize modern coding techniques, but their purpose is not to teach other dimensions of web engineering, e.g., localization and robust platform interoperability. + Further information about platform and browser support is conveyed in the + Read Me First. +

    +
    + +
    +

    Important Prerequisite Knowledge

    +

    + The APG Task Force strives to make the APG welcoming to a broad audience by using plane and simple language wherever possible. + Consequently, even readers with minimal understanding of web development or accessibility can benefit from a significant portion of the guidance, e.g., the keyboard interaction patterns. + At the same time, many topics addressed by the APG are inherently complex and call for technically precise terminology. + Additionally, some important aspects of creating accessible experiences fall outside the scope of the APG. + This section describes the types of prerequisite knowledge and supporting resources that may enable readers to derive maximum benefit from the APG. +

    +

    + Broadly speaking, the APG blends accessibility, UI design, and web engineering. + To successfully utilize the APG, it is not necessary for readers to have working knowledge in all three disciplines. + Accessibility specialists will find the APG more beneficial with at least a rudimentary understanding of HTML and CSS while designers and engineers will need familiarity with some accessibility fundamentals. + All readers will need a firm grasp of some basic ARIA concepts. +

    +

    + People who understand web design or engineering but are not familiar with accessibility and assistive technologies may be able to implement much of the guidance provided by the patterns and example code. + However, because many aspects of the guidance are neither prescriptive nor comprehensive, readers may need to make decisions that require assessing tradeoffs that could impact users with disabilities. + In addition to having some understanding of the needs of people with disabilities and the role of assistive technologies in satisfying them, it is essential that developers can perform some testing. + Relevant resources for developing an understanding of accessibility and assistive technologies include: +

    + +

    + Readers who already have sufficient familiarity with accessibility and assistive technologies also need an understanding the purpose of ARIA and what accessibility semantics are. + These topics are covered by ARIA Basics. +

    +
    + +
    +

    How the APG is Organized

    +

    + The APG is organized into the following major sections. + Note that as advised in several places throughout the APG, it is important to understand the information presented in the + Read Me First + before utilizing any of the patterns or practices. +

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    SectionDescription
    Patterns + A library of more than 30 common user interface patterns, ranging from typical buttons and popup menus to complex tree grids. + Each pattern describes its purpose, keyboard interaction model, accessibility semantics, and is complemented by one or more illustrative functional example implementations. +
    Practices + Gives in-depth explanation of how to satisfy a variety of accessibility needs that surface when making rich internet application experiences accessible, such as providing accessible names, enabling keyboard interaction, conveying page structure to assistive technologies, and supporting high contrast operating system settings. + For instance, the practices section on providing accessible names and descriptions gives detailed descriptions of seven different naming techniques as well as a table providing guidance for naming more than 80 types of elements. +
    Index + Provides multiple indexes of example implementations of patterns, e.g., examples listed by ARIA role, state, and property. +
    About + Provides information about the APG, such as the introduction, acknowledgements, coverage and quality reports, and more. +
    +
    + +
    + + diff --git a/content/about/related-specifications/related-specifications.html b/content/about/related-specifications/related-specifications.html new file mode 100644 index 0000000000..d70115f78d --- /dev/null +++ b/content/about/related-specifications/related-specifications.html @@ -0,0 +1,81 @@ + + + + + + Related Specifications + + + + + + + + + +
    +

    Related Specifications

    + +
    +

    References

    +
    +

    Informative references

    +
    +
    [HTML]
    +
    + + HTML Standard + + . Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living + Standard. URL: + https://html.spec.whatwg.org/multipage/ +
    +
    [HTML-AAM]
    +
    + + HTML Accessibility API Mappings 1.0 + + . Steve Faulkner; Scott O'Hara. W3C. 26 October 2022. W3C Working Draft. URL: + https://www.w3.org/TR/html-aam-1.0/ +
    +
    [HTML-ARIA]
    +
    + + ARIA in HTML + + . Steve Faulkner; Scott O'Hara; Patrick Lauke. W3C. 27 September 2022. W3C Recommendation. URL: + https://www.w3.org/TR/html-aria/ +
    +
    [SVG2]
    +
    + + Scalable Vector Graphics (SVG) 2 + + . Amelia Bellamy-Royds; Bogdan Brinza; Chris Lilley; Dirk Schulze; David Storey; Eric Willigers. W3C. 4 + October 2018. W3C Candidate Recommendation. URL: + https://www.w3.org/TR/SVG2/ +
    +
    [WAI-ARIA]
    +
    + + Accessible Rich Internet Applications (WAI-ARIA) 1.1 + + . Joanmarie Diggs; Shane McCarron; Michael Cooper; Richard Schwerdtfeger; James Craig. W3C. 14 December 2017. + W3C Recommendation. URL: + https://www.w3.org/TR/wai-aria-1.1/ +
    +
    [WAI-ARIA-1.2]
    +
    + + Accessible Rich Internet Applications (WAI-ARIA) 1.2 + + . Joanmarie Diggs; James Nurthen; Michael Cooper. W3C. 8 December 2021. W3C Candidate Recommendation. URL: + https://www.w3.org/TR/wai-aria-1.2/ +
    +
    +
    +
    + +
    + + diff --git a/cspell.json b/cspell.json index 5c7bf3671f..56ec17a542 100644 --- a/cspell.json +++ b/cspell.json @@ -1,9 +1,14 @@ { "version": "0.2", - "dictionaries": ["html", "css", "javascript", "npm"], + "dictionaries": [ + "html", + "css", + "javascript", + "npm" + ], "words": [ - "Accesskey", "accesskey", + "Accesskey", "activedescendants", "affordance", "Ahlefeldt", @@ -43,6 +48,7 @@ "contentinfos", "Cook'n", "Copernicium", + "Corthals", "Coughlin", "crossorigin", "cufc", @@ -107,9 +113,9 @@ "Jaeun", "jarosewli", "Jemma", + "Jèrôme", "Jinyuan", "Joanmarie", - "Jèrôme", "Kasper", "kbdshortcuts", "Kesteren", @@ -141,8 +147,8 @@ "moreaccessible", "Moscovium", "MSAA", - "multithumb", "Müller", + "multithumb", "navs", "Nemeth", "nightmode", @@ -194,6 +200,7 @@ "Scrollable", "Seaborgium", "Seckel", + "Ségur", "Shirisha", "shizzle", "Shopify", @@ -212,11 +219,10 @@ "submenu's", "submenus", "Sulaiman", - "Ségur", "tabbable", "tablist", - "tablists", "tablist’s", + "tablists", "tabpanels", "Tatiana", "Tennessine", @@ -226,7 +232,6 @@ "Theresia", "Thiel", "Thiers", - "thomascorthals", "togglable", "Tonekunstnerinde", "transactinide",