w3c · nschonni · May 21, 2026 · May 21, 2026 · May 21, 2026 · May 21, 2026
diff --git a/accname/index.html b/accname/index.html
@@ -483,7 +483,7 @@ <h4>Computation steps</h4>
                   </div>
                   <aside class="example">
                     <p>
-                      The following examples show the meaning of the clause "Not part of an <code>aria-labelledby</code> or <code>aria-describedby</code> traversal, where the node directy referenced
+                      The following examples show the meaning of the clause "Not part of an <code>aria-labelledby</code> or <code>aria-describedby</code> traversal, where the node directly referenced
                       by that relation was hidden.".
                     </p>
                     <p>

diff --git a/common/script/aria.js b/common/script/aria.js
@@ -199,7 +199,7 @@ const buildRoleInfoPropList = function (roleInfo, propList, item) {
  * @returns
  */
 const buildAllprops = function (role) {
-  // TODO: pkra would like to use sets here but allprops part of roleInfo serializaton
+  // TODO: pkra would like to use sets here but allprops part of roleInfo serialization
   const ref = roleInfo[role];
   if (!ref) {
     msg.pub("error", "No role definition for " + role);

diff --git a/common/script/prComment.mjs b/common/script/prComment.mjs
@@ -68,7 +68,7 @@ async function updatePRDescription(markdownContent) {
 
     // Create new body with preview links prepended
     const newBody = `🚀 **Netlify Preview**:
-🔄 **this PR updates the following sspecs**:
+🔄 **this PR updates the following specs**:
 ${markdownContent}
 
 ${cleanedBody}`.trim();

diff --git a/core-aam/index.html b/core-aam/index.html
@@ -591,7 +591,7 @@ <h2>Computed Role</h2>
             >
           </aside>
           <p>
-            When host language elements do not have an exact or equivalent mapping to a valid, non-abstract role, the related Accessibilty API Mapping extension specification MAY specify a unique
+            When host language elements do not have an exact or equivalent mapping to a valid, non-abstract role, the related Accessibility API Mapping extension specification MAY specify a unique
             `computedrole` string as the return value for interoperability testing purposes, such as `&lt;video&gt; -&gt; "html-video"` in [[HTML-AAM]]. However, authors MUST NOT use any
             host-language-prefixed `computedrole` string in the `role` attribute (such as `html-video`), unless the token also matches valid, defined role (such as `dpub-chapter`). User Agents MUST
             ignore any abstract or invalid role token.
@@ -4943,7 +4943,7 @@ <h4 id="role-map-separator"><code>separator</code> (non-focusable)</h4>
               <tr>
                 <th>Computed Role</th>
                 <td>
-                  <p><code>seperator</code></p>
+                  <p><code>separator</code></p>
                 </td>
               </tr>
               <tr>
@@ -4995,7 +4995,7 @@ <h4 id="role-map-separator-focusable"><code>separator</code> (focusable)</h4>
               <tr>
                 <th>Computed Role</th>
                 <td>
-                  <p><code>seperator</code></p>
+                  <p><code>separator</code></p>
                 </td>
               </tr>
               <tr>

diff --git a/documentation/archive/1.2/Resolving ARIA 1.1 Combobox Issues.md b/documentation/archive/1.2/Resolving ARIA 1.1 Combobox Issues.md
@@ -65,7 +65,7 @@ As described above, ARIA 1.1 specifies the combobox structure to be a combobox c
 
 More detail is provided about each of the following problems in sections below. Each of these problems has spawned multiple issues against the ARIA spec.
 
-1. Naming: In code, there are 3 parts that can be named -- the combobox, the input, and the popup. On the screen, there is only one thing rendered that needs an accessible name -- the input. The spec says to name only the container. But, the spec does not require the browser to compute a name for the input from the container, which leads to an unlabeled input fieled, violating WCAG. Thus, authors tend to name all three parts, which creates verbosity problems that are difficult for screen reader developers to mitigate.
+1. Naming: In code, there are 3 parts that can be named -- the combobox, the input, and the popup. On the screen, there is only one thing rendered that needs an accessible name -- the input. The spec says to name only the container. But, the spec does not require the browser to compute a name for the input from the container, which leads to an unlabeled input field, violating WCAG. Thus, authors tend to name all three parts, which creates verbosity problems that are difficult for screen reader developers to mitigate.
 2. Screen reader presentation of the container: The container is sometimes being partially rendered by screen readers as a group. This adds elements to the screen reader experience that do not exist on screen and do not add value. In fact, it can be confusing for screen reader users because these extra grouping elements have never previously been part of how screen readers present comboboxes.
 3. Screen reader presentation of the input: The ARIA spec says the wrapper has the `combobox` role but does not state what the role of the input should be. This is critical because the input is what gets focused. The spec needs to tell screen readers how the input should be conveyed to users.
 4. Lack of `select` support: There is a type of combobox that does not include a textbox. HTML:select@size=1 is one example of this. This type of control cannot be created using the ARIA 1.1 combobox definition.
@@ -143,7 +143,7 @@ An expanded combobox renders only two elements that are intrinsically related by
 This is similar to other ARIA widgets that conditionally display a secondary element, such as disclosures and menu buttons.
 Those patterns do not superimpose a semantic grouping container; doing so would add authoring complexity without improving the experience for end users.
 
-If ARIA 1.2 does not eliminate the container from the combobox specification, then it could help resolve this problem by adding a normative statement that says assistive technologies SHOULD NOT expose the container to users. This would align with prohibitting accessible names on the container.
+If ARIA 1.2 does not eliminate the container from the combobox specification, then it could help resolve this problem by adding a normative statement that says assistive technologies SHOULD NOT expose the container to users. This would align with prohibiting accessible names on the container.
 
 ### Resolving problems with Screen reader presentation of ARIA 1.1 combobox input
 
@@ -189,7 +189,7 @@ The ARIA 1.1 combobox pattern is relatively complex due to the fact that there a
 This has been a source of author errors.
 At least one screen reader developer is identifying such errors as a significant concern.
 
-Short of eliminating the container, there is no clear way to mitigate this other than to encourage browsers to correct author errors when populating the accessibility tree. Of course, checkers can help prevent the errors from getting out in the wild. But, that will not remove the necessaty of robust error correction.
+Short of eliminating the container, there is no clear way to mitigate this other than to encourage browsers to correct author errors when populating the accessibility tree. Of course, checkers can help prevent the errors from getting out in the wild. But, that will not remove the necessity of robust error correction.
 
 ## Summary of resolution options
 

diff --git a/documentation/archive/process/Monorepo Project.md b/documentation/archive/process/Monorepo Project.md
@@ -19,7 +19,7 @@ We will move after the recharter:
 ARIA [Monorepo](https://github.com/w3c/aria/tree/monorepo) branch starts off with a basic structure + some demo GitHub workflows for publication.
 Open questions:
 * What other specs use a monorepo, what is their insight on this proposal?
-  * [ePub Working Group](https://github.com/w3c/epub-specs) is currently using a "monorepo" approach. Publlishing ever-green specs is doable with current [specprod options](https://w3c.github.io/spec-prod/#options). Daniel will set up a proposal for handling our specs.
+  * [ePub Working Group](https://github.com/w3c/epub-specs) is currently using a "monorepo" approach. Publishing ever-green specs is doable with current [specprod options](https://w3c.github.io/spec-prod/#options). Daniel will set up a proposal for handling our specs.
 * How to publish the different specifications from one repo
    * How to publish evergreen vs versioned specifications
      * Daniel suggests that we use automated publication for ever-green specs but we keep using manual publication for versioned specs. Most transition requests need to happen manually anyway.
@@ -29,7 +29,7 @@ Open questions:
 * Whether to leave repositories open for issue tracking
 * Are modifications necessary for pr-preview?
 * What will we do with open PRs?
-* Do we want to take the time to change some old branch mnaming and usage? HTML-aam still uses gh-pages as the main branch.
+* Do we want to take the time to change some old branch naming and usage? HTML-aam still uses gh-pages as the main branch.
 
 Example of monorepos:
 * https://github.com/w3c/epub-specs

diff --git a/documentation/browser_accessibility_heuristics.md b/documentation/browser_accessibility_heuristics.md
@@ -4,7 +4,7 @@
 The following is an incomplete, running list of known heuristics in browsers that could result in potentially different behavior. The goal of this list is provide insights into existing behavior (for spec authors or browser engine implementors), and possibly to consider these for reconciliation, standardization, and specification.
 
 
-## Examples of Browser Heuristics Already Added to Accesibility Specs
+## Examples of Browser Heuristics Already Added to Accessibility Specs
 
 ### Ignoring aria-hidden when applied to the root or document elements
 

diff --git a/documentation/tests.md b/documentation/tests.md
@@ -68,7 +68,7 @@ When the IDL Interface section is updated, these tests should be update accordin
 
 ### Interop 2023 Accessibility Investigation 
 
-Many of the automated tests in listed above started as a [Accessibility Investigation](https://github.com/web-platform-tests/interop-2023-accessibility-testing) for Web Platform Tests Interop 2023. Revew the [Issues List](https://github.com/web-platform-tests/interop-2023-accessibility-testing/issues) and [Scoring Criteria](https://github.com/web-platform-tests/interop-2023-accessibility-testing/issues/3) for more detail.
+Many of the automated tests in listed above started as a [Accessibility Investigation](https://github.com/web-platform-tests/interop-2023-accessibility-testing) for Web Platform Tests Interop 2023. Review the [Issues List](https://github.com/web-platform-tests/interop-2023-accessibility-testing/issues) and [Scoring Criteria](https://github.com/web-platform-tests/interop-2023-accessibility-testing/issues/3) for more detail.
 
 ### Running (and writing) WPT Tests for ARIA and Related Specs
 

diff --git a/documentation/wpt.md b/documentation/wpt.md
@@ -94,7 +94,7 @@ Note: Chrome does not give a similar Security prompt. I presume it stops the ses
 - Check the META.yml file in those directories to find the primary reviewers. 
 - Review [/wai-aria/scripts/aria-utils.js](https://github.com/web-platform-tests/wpt/blob/master/wai-aria/scripts/aria-utils.js), as this contains a few convenience methods many of the other tests use.
 - WPT doesn't require an Issue for every PR, but you're welcome (encouraged) to file WPT Issues in the relevant spec repository. (E.g., /w3c/aria/issues/new for a new ARIA WPT test, rather than /web-platform-tests/wpt/issues/new).
-- Some issues are being tracked elsewhere, for example, the [Interop 2023 Accessibilty Investigation](https://github.com/web-platform-tests/interop-accessibility/issues)
+- Some issues are being tracked elsewhere, for example, the [Interop 2023 Accessibility Investigation](https://github.com/web-platform-tests/interop-accessibility/issues)
 - Additional info in the [ARIA "Tests" documentation](./tests.md)
 
 
@@ -108,7 +108,7 @@ When you write a new test in WPT, or update an existing one, wait for the PR Che
 
 Once you select a test result:
 
-1. Click on the Details link for either safari or chrome. (At the time of this writing, firefox was not running most of the accessibilty tests in WPT)
+1. Click on the Details link for either safari or chrome. (At the time of this writing, firefox was not running most of the accessibility tests in WPT)
 2. On the results page, click "Visual comparison of the results"… Explore these results similar to the CI listings on wpt.fyi
 3. Once you get down to an individual test run, you may also wish to enabled the "Show Details" switch to see the log messages for each failing subtest.
 
diff --git a/dpub-aam/index.html b/dpub-aam/index.html
@@ -640,7 +640,7 @@ <h4 id="role-map-bibliography"><code>doc-bibliography</code></h4>
                     <li>Control Type is <code>Text</code></li>
                     <li>Localized Control Type is '<code>bibliography</code>'</li>
                     <li>Landmark Type is <code>Custom</code></li>
-                    <li>Localized Landmark Type is '<code>biblography</code>'</li>
+                    <li>Localized Landmark Type is '<code>bibliography</code>'</li>
                   </ul>
                 </td>
               </tr>
@@ -2621,7 +2621,7 @@ <h2>Security Considerations</h2>
       <h2>Privacy Considerations</h2>
 
       <p>
-        In accordance with <a href="https://w3ctag.github.io/design-principles/#do-not-expose-use-of-assistive-tech">Web Platform Design Principles</a>, this specification provides no programatic
+        In accordance with <a href="https://w3ctag.github.io/design-principles/#do-not-expose-use-of-assistive-tech">Web Platform Design Principles</a>, this specification provides no programmatic
         interface to determine if information is being used by assistive technologies. However, this specification does allow an author to present different information to users of assistive
         technologies from the information available to users who do not use assistive technologies. This is possible using many features of the DPUB-ARIA specification, just as this is possible using
         many other parts of the web technology stack. This content disparity could be abused to perform <a data-cite="fingerprinting-guidance#active-0">active fingerprinting</a> of users of assistive

diff --git a/dpub-aria/index.html b/dpub-aria/index.html
@@ -278,7 +278,7 @@ <h4>Testing Practices and Tools</h4>
 
           <p>
             The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content need to test for device-independent access to
-            <a data-lt="widget">widgets</a> and applications, and verify accessibility <abbr title="application programing interface">API</abbr> access to all content and changes during user
+            <a data-lt="widget">widgets</a> and applications, and verify accessibility <abbr title="application programming interface">API</abbr> access to all content and changes during user
             interaction.
           </p>
         </section>
@@ -2583,7 +2583,7 @@ <h3>Definition of Roles</h3>
 
             <pre class="example highlight">
 &lt;section role="doc-glossary" aria-labelledby="glosshd"&gt;
-   &lt;h2 id="glosshd">Glossay of Technical Terms&lt;/h2>
+   &lt;h2 id="glosshd">Glossary of Technical Terms&lt;/h2>
    &lt;ul&gt;
       &lt;li id="gtt00110001">&lt;dfn>algorithm&lt;/dfn> A set of rules &#8230;&lt;/li>
       &#8230;
@@ -4422,8 +4422,8 @@ <h2>Security Considerations</h2>
       <h2>Privacy Considerations</h2>
 
       <p>
-        In accordance with <a href="https://w3ctag.github.io/design-principles/#do-not-expose-use-of-assistive-tech">Web Platform Design Principles</a>, this specification provides no programatic
-        interface to determine if information is being used by assistive technologies. However, this specificaton does allow an author to present different information to users of assistive
+        In accordance with <a href="https://w3ctag.github.io/design-principles/#do-not-expose-use-of-assistive-tech">Web Platform Design Principles</a>, this specification provides no programmatic
+        interface to determine if information is being used by assistive technologies. However, this specification does allow an author to present different information to users of assistive
         technologies from the information available to users who do not use assistive technologies. This is possible using many features of the DPUB-ARIA specification, just as this is possible using
         many other parts of the web technology stack. This content disparity could be abused to perform <a data-cite="fingerprinting-guidance#active-0">active fingerprinting</a> of users of assistive
         technologies.

diff --git a/graphics-aam/index.html b/graphics-aam/index.html
@@ -242,7 +242,7 @@ <h2>Introduction</h2>
       <ul>
         <li>
           <cite><a href="https://www.w3.org/TR/wai-aria-1.1/">Accessible Rich Internet Applications (WAI-ARIA) 1.1</a></cite> [[WAI-ARIA-1.1]], a planned
-          <abbr title="World Wide Web Consortium">W3C</abbr> recommendation that extends the exising ARIA standard [[WAI-ARIA-1.0]]. It defines the core roles, states, and properties.
+          <abbr title="World Wide Web Consortium">W3C</abbr> recommendation that extends the existing ARIA standard [[WAI-ARIA-1.0]]. It defines the core roles, states, and properties.
         </li>
         <li>
           <cite><a href="https://www.w3.org/TR/graphics-aria-1.0/">WAI-ARIA Graphics Module</a></cite> [[GRAPHICS-ARIA-1.0]], a planned

diff --git a/graphics-aria/img/house-graphicsroles.svg b/graphics-aria/img/house-graphicsroles.svg
diff --git a/graphics-aria/index.html b/graphics-aria/index.html
@@ -369,7 +369,7 @@ <h2>Assistive Technologies</h2>
             descriptions, preserving any meaningful structure and relationships between components.
           </li>
           <li>
-            Alternative graphical presentations, such as colour-adjusted displays, screen magnifiers, large print documents, or embossing printers with graphic support. These technologies need to
+            Alternative graphical presentations, such as color-adjusted displays, screen magnifiers, large print documents, or embossing printers with graphic support. These technologies need to
             distinguish between graphical features which are primarily decorative and those which are essential for conveying the meaning of the content.
           </li>
         </ul>