Standardize a11y header (#31180)

* Standardize header

* Standardize header

files/en-us/web/accessibility/aria/roles/separator_role/index.md

@@ -110,7 +110,7 @@ From the assistive technology user's perspective, the heading does not exist sin
 
 ## Examples
 
-## Accessibility Concerns
+## Accessibility concerns
 
 ## Best Practices
 

files/en-us/web/accessibility/aria/roles/tablist_role/index.md

@@ -79,7 +79,7 @@ When focus is on a tab in a tablist with either horizontal or vertical orientati
 <!--
 ### Required JavaScript features
 
-## Accessibility Concerns
+## Accessibility concerns
 
 ## Best Practices
 

files/en-us/web/accessibility/aria/roles/term_role/index.md

@@ -68,7 +68,7 @@ or without any ARIA (but possibly not how you want it presented)
 </dl>
 ```
 
-## Accessibility Concerns
+## Accessibility concerns
 
 Don't use the `role="term"` on interactive elements such as links as it can interfere with the assistive technology user's ability to interact with the element.
 

files/en-us/web/accessibility/aria/roles/toolbar_role/index.md

@@ -86,7 +86,7 @@ When the toolbar has focus within it, provide visual cues. When an element withi
 
 [Toolbar example from <abbr>W3C</abbr>, the World Wide Web Consortium](https://www.w3.org/TR/wai-aria-practices-1.2/examples/toolbar/toolbar.html)
 
-## Accessibility Concerns
+## Accessibility concerns
 
 Avoid including controls whose operation requires arrow keys used for toolbar navigation (right and left arrows, or top and bottom for vertical toolbars). If you must include such a control, make it the last control in the toolbar. For example, in a horizontal toolbar, a textbox could be included as the last element.
 

files/en-us/web/accessibility/aria/roles/tooltip_role/index.md

@@ -95,7 +95,7 @@ The tooltip can be instantiated with CSS. Change the class name with JavaScript
 
 The above hides the tooltip with CSS in the default state or if the hidetooltip class has been added with JavaScript (when the user hit <kbd>Escape</kbd>), with high specificity to ensure the tooltip doesn't show. When the owning element receives focus, it gets positioned relatively and the tooltip becomes visible.
 
-## Accessibility Concerns
+## Accessibility concerns
 
 If the information is important enough for a tooltip, isn't it important enough to always be visible?
 

files/en-us/web/accessibility/aria/roles/treegrid_role/index.md

@@ -137,7 +137,7 @@ While navigation keys, such as arrow keys, are moving focus from cell to cell, t
 ## Examples
 -->
 
-## Accessibility Concerns
+## Accessibility concerns
 
 It is important for all cells to be able to receive or contain keyboard focus because screen readers are generally in application reading mode, rather than their document reading mode, when users are interacting with the grid. While in application mode, a screen reader user hears only focusable elements and content that labels focusable elements. If content can't receive focus, screen reader users may unknowingly overlook elements contained in the treegrid.
 

files/en-us/web/api/window/open/index.md

@@ -254,7 +254,7 @@ console.log(sameOriginContext.origin);
 
 For more information, refer to the [Same-origin policy](/en-US/docs/Web/Security/Same-origin_policy) article.
 
-## Accessibility
+## Accessibility concerns
 
 ### Avoid resorting to window.open()
 

files/en-us/web/css/color_value/index.md

@@ -177,7 +177,7 @@ the preprocessing procedure is:
    oklch(63.612% 0.1522 78.748)
    ```
 
-## Accessibility considerations
+## Accessibility concerns
 
 Some people have difficulty distinguishing colors. The [WCAG 2.2](/en-US/docs/Web/Accessibility/Understanding_WCAG/Perceivable/Use_of_color) recommendation strongly advises against using color as the only means of conveying a specific message, action, or result. See [color and color contrast](/en-US/docs/Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast) for more information.
 

files/en-us/web/css/important/index.md

@@ -142,7 +142,7 @@ Even when working to override high-specificity styles not under your control, su
 
 If you need to override an external stylesheet containing important declarations, create a cascade layer containing the needed overrides, and declare that layer first.
 
-### Accessibility
+### Accessibility concerns
 
 Important styles from a user stylesheet take precedence over the author style sheet's important declarations, meaning adding an `!important` flag to a site's styles will not prevent individual users with special requirements, such as large fonts, from being able to override your styles by adding important styles in their own user's style sheet.
 

files/en-us/web/html/attributes/pattern/index.md

@@ -142,7 +142,7 @@ This renders like so:
 
 {{ EmbedLiveSample('Specifying_a_pattern', 600, 110) }}
 
-### Accessibility Concerns
+### Accessibility concerns
 
 When a control has a `pattern` attribute, the `title` attribute, if used, must describe the pattern. Relying on the `title` attribute for the visual display of text content is generally discouraged as many user agents do not expose the attribute in an accessible manner. Some browsers show a tooltip when an element with a title is hovered, but that leaves out keyboard-only and touch-only users. This is one of the several reasons you must include information informing users how to fill out the control to match the requirements.
 

files/en-us/web/html/element/a/index.md

@@ -268,7 +268,7 @@ document
 
 Using `target="_blank"` without [`rel="noreferrer"`](/en-US/docs/Web/HTML/Attributes/rel/noreferrer) and [`rel="noopener"`](/en-US/docs/Web/HTML/Attributes/rel/noopener) makes the website vulnerable to {{domxref("window.opener")}} API exploitation attacks, although note that, in newer browser versions setting `target="_blank"` implicitly provides the same protection as setting `rel="noopener"`. See [browser compatibility](#browser_compatibility) for details.
 
-## Accessibility
+## Accessibility concerns
 
 ### Strong link text
 

files/en-us/web/html/element/dialog/index.md

@@ -547,7 +547,7 @@ The code renders as follows:
   </tbody>
 </table>
 
-## Accessibility considerations
+## Accessibility concerns
 
 When implementing a dialog, it is important to consider the most appropriate place to set user focus. When using {{domxref("HTMLDialogElement.showModal()")}} to open a `<dialog>`, focus is set on the first nested focusable element. Explicitly indicating the initial focus placement by using the [`autofocus`](/en-US/docs/Web/HTML/Global_attributes/autofocus) attribute will help ensure initial focus is set on the element deemed the best initial focus placement for any particular dialog. When in doubt, as it may not always be known where initial focus could be set within a dialog, particularly for instances where a dialog's content is dynamically rendered when invoked, the `<dialog>` element itself may provide the best initial focus placement.
 

files/en-us/web/html/element/header/index.md

@@ -64,7 +64,7 @@ This element only includes the [global attributes](/en-US/docs/Web/HTML/Global_a
 
 {{EmbedLiveSample('Article Header')}}
 
-## Accessibility
+## Accessibility concerns
 
 The `<header>` element defines a [`banner`](/en-US/docs/Web/Accessibility/ARIA/Roles/banner_role) landmark when its context is the {{HTMLElement('body')}} element. The HTML header element is not considered a banner landmark when it is descendant of an {{HTMLElement('article')}}, {{HTMLElement('aside')}}, {{HTMLElement('main')}}, {{HTMLElement('nav')}}, or {{HTMLElement('section')}} element.
 

files/en-us/web/html/element/input/number/index.md

@@ -390,7 +390,7 @@ After declaring a few variables, an event listener is added to the `button` to c
 >
 > If you didn't do this, you'd have to fill in both feet/inches **and** meters to submit the form!
 
-## Accessibility
+## Accessibility concerns
 
 The implicit [role](/en-US/docs/Web/Accessibility/ARIA/Roles) for the `<input type="number">` element is [`spinbutton`](/en-US/docs/Web/Accessibility/ARIA/Roles/spinbutton_role). If spinbutton is not an important feature for your form control, consider _not_ using `type="number"`. Instead, use [`inputmode="numeric"`](/en-US/docs/Web/HTML/Global_attributes/inputmode) along with a [`pattern`](/en-US/docs/Web/HTML/Attributes/pattern) attribute that limits the characters to numbers and associated characters. With `<input type="number">`, there is a risk of users accidentally incrementing a number when they're trying to do something else. Additionally, if users try to enter something that's not a number, there's no explicit feedback about what they're doing wrong.
 

files/en-us/web/html/element/output/index.md

@@ -42,7 +42,7 @@ In the following example, the form provides a slider whose value can range betwe
 
 {{ EmbedLiveSample('Examples')}}
 
-## Accessibility Concerns
+## Accessibility concerns
 
 Many browsers implement this element as an [`aria-live`](/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions) region. Assistive technology will thereby announce the results of UI interactions posted inside it without requiring that focus is switched away from the controls that produce those results.
 

files/en-us/web/html/element/progress/index.md

@@ -79,7 +79,7 @@ This element includes the [global attributes](/en-US/docs/Web/HTML/Global_attrib
 
 {{ EmbedLiveSample("Examples", 200, 50) }}
 
-## Accessibility Concerns
+## Accessibility concerns
 
 ### Labelling
 

files/en-us/web/html/element/search/index.md

@@ -17,7 +17,7 @@ This element only includes the [global attributes](/en-US/docs/Web/HTML/Global_a
 
 The `<search>` element is not for presenting search results. Rather, search or filtered results should be presented as part of the main content of that web page. That said, suggestions and links that are part of "quick search" functionality within the search or filtering functionality are appropriately nested within the contents of the `<search>` element as they are search features.
 
-## Accessibility
+## Accessibility concerns
 
 The `<search>` element defines a [`search`](/en-US/docs/Web/Accessibility/ARIA/Roles/search_role) landmark. This removes the need for adding `role=search` to a {{HTMLElement('form')}} element.
 

files/en-us/web/html/global_attributes/autofocus/index.md

@@ -17,7 +17,7 @@ No more than one element in the document or dialog may have the autofocus attrib
 
 > **Note:** The `autofocus` attribute applies to all elements, not just form controls. For example, it might be used on a [contenteditable](/en-US/docs/Web/HTML/Global_attributes/contenteditable) area.
 
-## Accessibility considerations
+## Accessibility concerns
 
 Automatically focusing a form control can confuse visually-impaired people using screen-reading technology and people with cognitive impairments. When `autofocus` is assigned, screen-readers "teleport" their user to the form control without warning them beforehand.
 

files/en-us/web/html/global_attributes/lang/index.md

@@ -36,7 +36,7 @@ The script subtag precedes the region subtag if both are present — `ru-Cyrl-BY
 
 To find the correct subtag codes for a language, try [the Language Subtag Lookup](https://r12a.github.io/app-subtags/).
 
-## Accessibility
+## Accessibility concerns
 
 WCAG Success Criterion 3.1.1 **requires** that a page language is specified in a way which may be 'programmatically determined' (i.e. via the **`lang`** attribute).