From ea7b05ed69807f939f4fd57ff6762f5128ebc21d Mon Sep 17 00:00:00 2001
From: Erin Donehoo <edonehoo@redhat.com>
Date: Wed, 11 Oct 2023 11:11:31 -0400
Subject: [PATCH 01/15] docs(accessibility-testing): Updates content as part of
 content audit.

---
 .../accessibility-testing.md                  | 109 +++++++++---------
 1 file changed, 52 insertions(+), 57 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 9f923719ef..f38a7ebef3 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -3,83 +3,79 @@ id: Testing your accessibility
 section: accessibility
 ---
 
-## General testing
+# Testing your product's accessibility 
 
-Many accessibility issues can be found by doing a few simple checks: 
-
-1. **Validate your HTML.** Structural, semantic HTML is the key starting point toward good accessibility practices. When a screen reader (or any sort of assistive device) scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page. No styles or JavaScript will be read by a screen reader. 
-
-   - Screen reader software like Voice Over, NVDA, or JAWS doesn’t just turn text into speech. It can use information in the HTML to list all of the headings on a page, give extra navigation controls to data tables, or announce how many items are in a list, among other things. This makes semantic HTML essential. 
-
-   - There are many tools you can use to validate your HTML, such as [W3C’s markup validation service](https://validator.w3.org/). 
-
-
-2. **Use an accessibility audit tool to check for violations.** If you are using PatternFly in your project, we recommend using [aXe: The Accessibility Engine](//www.deque.com/axe/) to check for accessibility violations locally. To make it even easier for you, we've created the [patternfly-a11y script](https://github.com/patternfly/patternfly-a11y) which reports any axe accessibility violations from a set of pages. A configuration file can be set to customize to specific needs like authentication, waiting for any specific items to finish loading (like a loading spinner), etc. When used as a report, it will give an output [similar to this example](http://a11y-os.surge.sh/). The UI should be built first in the CI workflow and then a job created to run the a11y script against that build. The a11y script assumes that there is a webserver running somewhere that is serving up the pages, i.e. in localhost:8000, that it can reach. If you want to test a step before deployment, you could follow the path of integrating axe with cypress. If you are contributing to PatternFly, refer to our [README.md](//github.com/patternfly/patternfly/blob/main/README.md#testing-for-accessibility) on how to run this tool.
-
-
-3. **Test keyboard accessibility, and check that these requirements are met:**
-    - All functionality is keyboard accessible.
-    - Elements in the HTML and in the layout follow a logical order.
-    - Elements with focus are clearly visible.
+The following guide contains instructions and recommendations to comprehensively test your product's accessibility to identify accessibility issues and opportunities for improvement.  
 
+## General testing recommendations 
 
-4. **Disable styles**, then test the information architecture and presence of adequate text labels. The [WAVE browser extension from WebAIM](//wave.webaim.org/extension/) provides this feature if it isn't available in the browser you are using.
+Many accessibility issues can be found by doing a few simple checks: 
 
+### 1. Validate your HTML
 
-5. **Test with any screen reader available in your operating system.** We target these screen readers to test PatternFly:
-    - JAWS with Chrome, Windows ([JAWS keyboard shortcuts](//dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts))
-    - Voiceover with Safari, Mac ([Voiceover keyboard shortcuts](//dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts))
-    - NVDA with Firefox, Windows ([NVDA keyboard shortcuts](//dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts))
+Good accessibility practices start with structural, semantic HTML. When a screen reader (or any sort of assistive device) scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page. No styles or JavaScript will be read by a screen reader. 
 
+Screen reader software like Voice Over (VO), NVDA, or JAWS doesn’t just turn text into speech. It can use information in the HTML to list all of the headings on a page, give extra navigation controls to data tables, announce how many items are in a list, and more. This makes semantic HTML essential. 
 
+There are many tools you can use to validate your HTML, such as [W3C’s markup validation service](https://validator.w3.org/). 
 
-6. **Check color contrast for the following:**
-    - Text color against background color ([Understanding WCAG 1.4.3](//www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html))
-    - Text color against link color ([Technique G183](//www.w3.org/TR/WCAG20-TECHS/G183.html))
-    - Visible boundaries of buttons and form elements against adjacent background color ([Understanding WCAG 1.4.11](//www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html))
+### 2. Check for accessibility violations with an audit tool
 
+ If you are using PatternFly, we recommend using [aXe: The Accessibility Engine](//www.deque.com/axe/) to check for accessibility violations locally. To make it even easier for you, we've created the [patternfly-a11y script](https://github.com/patternfly/patternfly-a11y), which reports any aXe accessibility violations from a set of pages. 
+ 
+ To use this script, a configuration file can be set to adapt our script to your specific needs like authentication, waiting for any specific items to finish loading (like a loading spinner), etc. 
+ 
+ When used as a report, it will give an output [similar to this example](http://a11y-os.surge.sh/). The UI should be built first in the CI workflow and then a job created to run the a11y script against that build. The a11y script assumes that there is a webserver running somewhere that is serving up the pages, i.e. in localhost:8000, that it can reach. If you want to test a step before deployment, you could follow the path of integrating axe with cypress. If you are contributing to PatternFly, refer to our [README.md](//github.com/patternfly/patternfly/blob/main/README.md#testing-for-accessibility) on how to run this tool.
 
 
-## Screen readers
-Just as front-end developers use their browser to see how their changes look, you should use a screen reader to see how your accessibility looks (we use Voice Over). 
+### 3. Test keyboard accessibility
 
-Generally, screen readers access the DOM (Document Object Model), and they use browser APIs (Application Programming Interfaces) to get the information they need. In this way, a screen reader knows what to say when a set of list items begins and ends, and it typically announces, in advance, how many items are in the list. A screen reader can also traverse a page using heading navigation to speak the heading level. 
+Because the keyboard is a key accessibility tool, it is necessary to ensure that the following requirements are met: 
 
-Here are a few aspects that can affect how screen readers communicate information:
+  - All functionality is keyboard accessible.
+  - Elements in the HTML and in the layout follow a logical order.
+  - Elements with focus are clearly visible.
 
-- **Semantic HTML**: Semantics refers to the meaning of a piece of code. A semantic element clearly describes its meaning to both the browser and the developer. For example, `<div>` and `<span>` are non-semantic elements because they don't describe their contents. Examples of semantic elements include `<form>` and `<table>`, which clearly define their contents. Screen readers expect semantic HTML when traversing the DOM, so non-semantic elements that aren't customized to be made accessible are highly likely to be inaccessible. Aria and other accessible attributes are meant to extend the functionality and meaning of native semantics, but at the core, your HTML should be semantic.
+### 4. Test without styles
 
-- **Headings**: A visual user can scan a page and fairly quickly understand its information architecture. Visually impaired users have other methods of achieving this. One common method is using heading levels to determine the flow of information. Headings that vary in size simply based on design and not functionality will likely confuse these users. A clear flow of sequential heading sizes based on headings and subheadings is significantly clearer to all users.
+Because screen readers cannot access style information, you should disable styles for your product and ensure that your information architecture is effective and that there are adequate text labels.
 
-- **Accessible names for all elements**: When an element doesn't have visual text or when further explanation is necessary, a screen reader will not know what an item is or does. For example, if you have an icon `<button>`, and it doesn't have a label, the screen reader can only tell that it’s a button—it can't determine what the button does. Add a few more non-labeled buttons, and now all the screen reader sees are vague buttons with no understanding of what they do. For more information, see the labeling section.
+ The [WAVE browser extension from WebAIM](//wave.webaim.org/extension/) provides this feature if it isn't available in the browser you are using.
 
-- **Links**: Similar to buttons, links should always have a label for clarity. Without the label, users have no idea where the links point to. If you have the same label for multiple links, each link must point to the same URL. Links, buttons, and form controls should make sense out of context. If a user wants to look at all of the links available, they should be able to differentiate the available links. You shouldn’t have multiple “Click here” links.
+### 5. Test with a screen reader 
 
-- **Landmarks**: Landmarks help communicate the structure of a page by identifying regions. There are many types of landmarks, such as banners, navigation, main, and form. When there are more than one of the same role (for example, two navigation regions on the same page), these regions should be differentiated by an `aria-label`.
+You can use any screen reader that is available in your operating system. To test PatternFly, we target the following screen readers:
+  - JAWS with Chrome, Windows ([JAWS keyboard shortcuts](//dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts))
+  - Voiceover with Safari, Mac ([Voiceover keyboard shortcuts](//dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts))
+  - NVDA with Firefox, Windows ([NVDA keyboard shortcuts](//dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts))
 
-- **Dynamic content**: One of the biggest accessibility concerns with dynamic content is the need to notify users that the content has changed. Sighted users benefit from highlighting or drawing visual attention to the changes. Non-sighted users need to be notified in another way, such as loading a new page, sending the focus to the new content, or using ARIA live announcements.
+### 6. Check color contrast
 
-- **Unrelated notifications**: Notifications from the operating system outside of the web app can interrupt a user while interacting with a page (for example, "You received a new chat message."). Consider this possibility when designing and developing for screen readers, and keep any notification messaging concise to limit the interruption.
+Colors should pass the following contrast checks, to ensure that users across the vision spectrum can understand your product:
+    - Text color against background color ([Understanding WCAG 1.4.3](//www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html))
+    - Text color against link color ([Technique G183](//www.w3.org/TR/WCAG20-TECHS/G183.html))
+    - Visible boundaries of buttons and form elements against adjacent background color ([Understanding WCAG 1.4.11](//www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html))
 
+## Accessibility testing checklist
 
-<br />
+We recommend referencing the following checklist as you assess your product's accessibility.
 
-### Checklist for testing
-These are some of the main areas we check for on the PatternFly team. We recommend that you check for these same areas in your applications, too. 
+These are some of the main areas we check for on the PatternFly team to ensure that components meet consistent accessibility standards, but, to check your complete implementation, we recommend checking these same areas in your products. 
 
-**General questions**
+### General criteria
 
 <label><input type="checkbox" /> VO Rotor Navigation can discover all information. </label><br/>
 <label><input type="checkbox" /> VO Shortcut Navigation can discover all information. </label><br/>
-<label><input type="checkbox" /> VO Cursor Navigation can discover all information (dependent on component and use case- easy way to navigate to component). </label><br/>
+<label><input type="checkbox" /> VO Cursor Navigation can discover all information (dependent on component and use case — there should be an easy way to navigate to the component). </label><br/>
 <label><input type="checkbox" /> Tabbed Keyboard Navigation can discover all information. </label>
-- However, if content should be hidden from a screen reader, for instance, if it’s offscreen or just presentational, make sure that content is set to aria-hidden=”true”.  <br/>
+- Unless content should be hidden from a screen reader (such as offscreen or presentational information) make sure that content is set to aria-hidden=”true”.  <br/>
 
-<label><input type="checkbox" /> Is it understandable and usable? </label><br/>
-  - <label><input type="checkbox" /> When you navigate to an item by keyboard or by screen reader, you can easily understand and use the item. </label><br/>
+<label><input type="checkbox" /> Items are understandable and usable. </label><br/>
+  - <label><input type="checkbox" /> When you navigate to an item by keyboard or by screen reader, you should be able to easily understand and use the item. </label><br/>
   - <label><input type="checkbox" /> The flow of information makes sense when navigating. Screen readers navigate the page in DOM order. If you used CSS to visually reposition elements, they might be announced in a nonsensical sequence. Instead, if you need something to appear earlier in the page, try to physically move it earlier in the DOM.</label>
 
-**Accessibility points** <br />
+### Accessibility points
+
 <label><input type="checkbox" /> **Structure:** The visual information architecture should map to the various rotor menus that exist by default. </label><br />
 - <label><input type="checkbox" /> **Check rotor:** Are there good headings, landmarks, links, form controls, and other elements? Do they make sense, and are they descriptive without overloading information? </label><br />
   - <label><input type="checkbox" /> Headings: Check that heading levels convey structure/content and do not skip. A common practice is to use a single h1 for the primary headline or logo on a page, h2s for designating major sections, and h3s for supporting sections. </label><br />
@@ -90,16 +86,15 @@ These are some of the main areas we check for on the PatternFly team. We recomme
 
 
 <label><input type="checkbox" /> **Labels:**</label>
-- <label><input type="checkbox" /> **Links:** Labels should be unique unless they have the same url. They should be descriptive/informative.</label>
+- <label><input type="checkbox" /> **Links:** Labels should be unique unless they have the same URL. They should be descriptive and informative.</label>
 - <label><input type="checkbox" /> **Buttons and form controls:**</label>
-  - Go through form controls and check if they all have labels. (Remember that there is a difference between being accessible and having a good, accessible experience. Clear, descriptive labels help create a better experience.)
-  - **Expandable buttons:** There should be some indication that it has the expandable control.
-- <label><input type="checkbox" /> **Form inputs:** These inputs should have some label even if it's not visible.</label>
-- <label><input type="checkbox" /> **Icons**: Where you don’t visibly see text there should still be some kind of text for screen reader.</label>
-- <label><input type="checkbox" /> **Images**: Check all images for proper alt text. The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string, e.g., `alt=””`.</label>
-- <label><input type="checkbox" /> **Landmarks:** Landmark regions should have labels when there is more than one type of landmark and they are not the same (navigation, main, form, etc.).
+  - Confirm that all form controls have effective labels. (Remember that there is a difference between being accessible and having a *good*, accessible experience. Clear, descriptive labels help create a better experience.)
+  - **Expandable buttons:** There should be some indication that a button has the expandable control.
+- <label><input type="checkbox" /> **Form inputs:** These inputs should have a label — even if it's not visible.</label>
+- <label><input type="checkbox" /> **Icons**: Even if you don’t visibly see text, there should still be some kind of text for screen readers.</label>
+- <label><input type="checkbox" /> **Images**: Check all images for proper alt text. The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string: `alt=””`.</label>
+- <label><input type="checkbox" /> **Landmarks:** Landmark regions should have labels when there is more than one type of landmark and they are not the same (such as navigation, main, form, etc.).
 Section element shouldn’t be used unless it has a label.</label>
-- <label><input type="checkbox" /> **Tables**: Can you tell what the table is and what’s in it? (https://webaim.org/techniques/tables/)</label>
-- <label><input type="checkbox" /> **Aria**: If there is visible text then there doesn’t need to be an `aria-label`. (Aria aids in description to screen reader users. It doesn’t have to reiterate or override what might already be there so you should check that your aria is useful.)</label>
-  - It’s important to understand that ARIA can only affect the _semantics_ of an element; it has no effect on the _behavior_ of the element. 
-  - For example, while you can make an element hidden to screen readers with `aria-hidden=”true”`, that does not change the focus behavior for that element. 
+- <label><input type="checkbox" /> **Tables**: Can you tell what the table is and what’s in it? [WebAIM has additional guidance on this.](https://webaim.org/techniques/tables/)</label>
+- <label><input type="checkbox" /> **Aria**: If there is visible text then there doesn’t need to be an `aria-label`. Aria provides more descriptive details to screen reader users. It doesn’t have to reiterate or override what might already be there so you should check that your aria is useful.</label>
+  - It’s important to understand that ARIA can only affect the _semantics_ of an element; it has no effect on the _behavior_ of the element. For example, while you can hide an element from screen readers with `aria-hidden=”true”`, that does not change the focus behavior for that element. 

From a843b8afcb13be37c8312b81f8679b1931ed6637 Mon Sep 17 00:00:00 2001
From: Erin Donehoo <105813956+edonehoo@users.noreply.github.com>
Date: Fri, 20 Oct 2023 15:28:44 -0400
Subject: [PATCH 02/15] Apply suggestions from code review

Co-authored-by: Eric Olkowski <70952936+thatblindgeye@users.noreply.github.com>
---
 .../accessibility-testing.md                  | 25 +++++++++++--------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index f38a7ebef3..38d9217be6 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -5,30 +5,33 @@ section: accessibility
 
 # Testing your product's accessibility 
 
-The following guide contains instructions and recommendations to comprehensively test your product's accessibility to identify accessibility issues and opportunities for improvement.  
+This guide contains instructions and recommendations to comprehensively test your product's accessibility to identify accessibility issues and opportunities for improvement.  
+
+**Keep in mind that this guide may not cover every scenario.**
+
 
 ## General testing recommendations 
 
 Many accessibility issues can be found by doing a few simple checks: 
 
-### 1. Validate your HTML
+### Validate your HTML
 
-Good accessibility practices start with structural, semantic HTML. When a screen reader (or any sort of assistive device) scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page. No styles or JavaScript will be read by a screen reader. 
+Good accessibility practices start with structural, semantic HTML. When a screen reader (or any sort of assistive technology) scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page. No styles or JavaScript will be read by a screen reader. 
 
 Screen reader software like Voice Over (VO), NVDA, or JAWS doesn’t just turn text into speech. It can use information in the HTML to list all of the headings on a page, give extra navigation controls to data tables, announce how many items are in a list, and more. This makes semantic HTML essential. 
 
 There are many tools you can use to validate your HTML, such as [W3C’s markup validation service](https://validator.w3.org/). 
 
-### 2. Check for accessibility violations with an audit tool
+### Check for accessibility violations with an audit tool
 
- If you are using PatternFly, we recommend using [aXe: The Accessibility Engine](//www.deque.com/axe/) to check for accessibility violations locally. To make it even easier for you, we've created the [patternfly-a11y script](https://github.com/patternfly/patternfly-a11y), which reports any aXe accessibility violations from a set of pages. 
+ If you are using PatternFly, we recommend using aXe: The Accessibility Engine (using their [DevTools](https://www.deque.com/axe/devtools/) or the [Chrome](https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd) or [Firefox](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/) extension) to check for accessibility violations locally. 
  
- To use this script, a configuration file can be set to adapt our script to your specific needs like authentication, waiting for any specific items to finish loading (like a loading spinner), etc. 
+We also offer the [patternfly-a11y script](https://github.com/patternfly/patternfly-a11y) for bulk testing that reports any aXe accessibility violations from a set of pages. To use this script, a configuration file can be set to adapt our script to your specific needs like authentication, waiting for any specific items to finish loading (like a loading spinner), etc. 
  
- When used as a report, it will give an output [similar to this example](http://a11y-os.surge.sh/). The UI should be built first in the CI workflow and then a job created to run the a11y script against that build. The a11y script assumes that there is a webserver running somewhere that is serving up the pages, i.e. in localhost:8000, that it can reach. If you want to test a step before deployment, you could follow the path of integrating axe with cypress. If you are contributing to PatternFly, refer to our [README.md](//github.com/patternfly/patternfly/blob/main/README.md#testing-for-accessibility) on how to run this tool.
+ When used as a report, it will give an [accessibility report via surge](http://a11y-os.surge.sh/). The UI should be built first in the CI workflow and then a job created to run the a11y script against that build. The a11y script assumes that there is a webserver running somewhere that is serving up the pages, i.e. in localhost:8000, that it can reach. If you want to test a step before deployment, you could follow the path of integrating axe with cypress.
 
 
-### 3. Test keyboard accessibility
+### Test keyboard accessibility
 
 Because the keyboard is a key accessibility tool, it is necessary to ensure that the following requirements are met: 
 
@@ -36,20 +39,20 @@ Because the keyboard is a key accessibility tool, it is necessary to ensure that
   - Elements in the HTML and in the layout follow a logical order.
   - Elements with focus are clearly visible.
 
-### 4. Test without styles
+### Test without styles
 
 Because screen readers cannot access style information, you should disable styles for your product and ensure that your information architecture is effective and that there are adequate text labels.
 
  The [WAVE browser extension from WebAIM](//wave.webaim.org/extension/) provides this feature if it isn't available in the browser you are using.
 
-### 5. Test with a screen reader 
+### Test with a screen reader 
 
 You can use any screen reader that is available in your operating system. To test PatternFly, we target the following screen readers:
   - JAWS with Chrome, Windows ([JAWS keyboard shortcuts](//dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts))
   - Voiceover with Safari, Mac ([Voiceover keyboard shortcuts](//dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts))
   - NVDA with Firefox, Windows ([NVDA keyboard shortcuts](//dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts))
 
-### 6. Check color contrast
+### Check color contrast
 
 Colors should pass the following contrast checks, to ensure that users across the vision spectrum can understand your product:
     - Text color against background color ([Understanding WCAG 1.4.3](//www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html))

From f116521e5b3f1e85407ba44da2e1d0cd65147a5e Mon Sep 17 00:00:00 2001
From: Erin Donehoo <105813956+edonehoo@users.noreply.github.com>
Date: Tue, 24 Oct 2023 17:59:45 -0400
Subject: [PATCH 03/15] Apply suggestions from code review

---
 .../content/developer-resources/accessibility-testing.md    | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 38d9217be6..5556175950 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -18,7 +18,7 @@ Many accessibility issues can be found by doing a few simple checks:
 
 Good accessibility practices start with structural, semantic HTML. When a screen reader (or any sort of assistive technology) scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page. No styles or JavaScript will be read by a screen reader. 
 
-Screen reader software like Voice Over (VO), NVDA, or JAWS doesn’t just turn text into speech. It can use information in the HTML to list all of the headings on a page, give extra navigation controls to data tables, announce how many items are in a list, and more. This makes semantic HTML essential. 
+Screen readers like Voice Over (VO), NVDA, or JAWS don't just turn text into speech. They use information in the HTML to list all of the headings on a page, give extra navigation controls to data tables, announce how many items are in a list, and more. This makes semantic HTML essential. 
 
 There are many tools you can use to validate your HTML, such as [W3C’s markup validation service](https://validator.w3.org/). 
 
@@ -28,12 +28,12 @@ There are many tools you can use to validate your HTML, such as [W3C’s markup
  
 We also offer the [patternfly-a11y script](https://github.com/patternfly/patternfly-a11y) for bulk testing that reports any aXe accessibility violations from a set of pages. To use this script, a configuration file can be set to adapt our script to your specific needs like authentication, waiting for any specific items to finish loading (like a loading spinner), etc. 
  
- When used as a report, it will give an [accessibility report via surge](http://a11y-os.surge.sh/). The UI should be built first in the CI workflow and then a job created to run the a11y script against that build. The a11y script assumes that there is a webserver running somewhere that is serving up the pages, i.e. in localhost:8000, that it can reach. If you want to test a step before deployment, you could follow the path of integrating axe with cypress.
+ When used as a report, it will give an [accessibility report via surge](http://a11y-os.surge.sh/). The UI should be built first in the CI workflow and then a job created to run the a11y script against that build. The a11y script assumes that there is a web server running somewhere that is serving up the pages  that it can reach. (for example, in localhost:8000). If you want to test a step before deployment, you could follow the path of integrating aXe with [Cypress](https://www.cypress.io/).
 
 
 ### Test keyboard accessibility
 
-Because the keyboard is a key accessibility tool, it is necessary to ensure that the following requirements are met: 
+The keyboard is an essential accessibility tool, so it is necessary to ensure that the following requirements are met: 
 
   - All functionality is keyboard accessible.
   - Elements in the HTML and in the layout follow a logical order.

From 3c10385c600bb9f8c88ee7be589ff4f855d606d0 Mon Sep 17 00:00:00 2001
From: Erin Donehoo <edonehoo@redhat.com>
Date: Thu, 26 Oct 2023 13:00:51 -0400
Subject: [PATCH 04/15] Content tweaks in progress.

---
 .../accessibility-testing.md                  | 60 ++++++++++---------
 1 file changed, 31 insertions(+), 29 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 5556175950..7f37417888 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -2,13 +2,13 @@
 id: Testing your accessibility
 section: accessibility
 ---
+import { Checkbox } from '@patternfly/react-core';
 
 # Testing your product's accessibility 
 
 This guide contains instructions and recommendations to comprehensively test your product's accessibility to identify accessibility issues and opportunities for improvement.  
 
-**Keep in mind that this guide may not cover every scenario.**
-
+**Keep in mind that this guide will not cover every scenario.**
 
 ## General testing recommendations 
 
@@ -48,9 +48,9 @@ Because screen readers cannot access style information, you should disable style
 ### Test with a screen reader 
 
 You can use any screen reader that is available in your operating system. To test PatternFly, we target the following screen readers:
-  - JAWS with Chrome, Windows ([JAWS keyboard shortcuts](//dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts))
-  - Voiceover with Safari, Mac ([Voiceover keyboard shortcuts](//dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts))
-  - NVDA with Firefox, Windows ([NVDA keyboard shortcuts](//dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts))
+  - [JAWS](https://www.freedomscientific.com/products/software/jaws/) with Chrome, Windows ([JAWS keyboard shortcuts](//dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts))
+  - [Voiceover](https://support.apple.com/guide/voiceover/welcome/mac) with Safari, Mac ([Voiceover keyboard shortcuts](//dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts))
+  - [NVDA](https://www.nvaccess.org/download/) with Firefox, Windows ([NVDA keyboard shortcuts](//dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts))
 
 ### Check color contrast
 
@@ -67,37 +67,39 @@ These are some of the main areas we check for on the PatternFly team to ensure t
 
 ### General criteria
 
-<label><input type="checkbox" /> VO Rotor Navigation can discover all information. </label><br/>
-<label><input type="checkbox" /> VO Shortcut Navigation can discover all information. </label><br/>
-<label><input type="checkbox" /> VO Cursor Navigation can discover all information (dependent on component and use case — there should be an easy way to navigate to the component). </label><br/>
-<label><input type="checkbox" /> Tabbed Keyboard Navigation can discover all information. </label>
+<Checkbox label="Rotor navigation can discover all information." id="general-criteria-1" /><br/>
+
+<Checkbox label="Shortcut navigation can discover all information."  description="For example, a keyboard shortcut that navigates between all headings on a page should discover all intended headings." /><br/>
+
+<Checkbox label="Cursor navigation can discover all applicable information." description="Some assistive technologies will have their own means of navigation and focus management. For example, VoiceOver uses a 'VO' key plus right or left arrow keys to navigate a page. This may be different than conventional keyboard navigation." id="general-criteria-3" /><br/>
+
+<Checkbox label="Keyboard navigation via the 'tab' key can discover all information. If content should be hidden from other assistive technology like a screen reader description="`className="ws-code">aria-hidden="true"</span>` should be passed to it." id="general-criteria-4" />
 - Unless content should be hidden from a screen reader (such as offscreen or presentational information) make sure that content is set to aria-hidden=”true”.  <br/>
 
-<label><input type="checkbox" /> Items are understandable and usable. </label><br/>
-  - <label><input type="checkbox" /> When you navigate to an item by keyboard or by screen reader, you should be able to easily understand and use the item. </label><br/>
-  - <label><input type="checkbox" /> The flow of information makes sense when navigating. Screen readers navigate the page in DOM order. If you used CSS to visually reposition elements, they might be announced in a nonsensical sequence. Instead, if you need something to appear earlier in the page, try to physically move it earlier in the DOM.</label>
+<Checkbox label="Items are understandable and usable." body={<Checkbox label="When you navigate to an item by keyboard or other assistive technology, you should be able to easily understand and use the item." id="general-criteria-5a" /><Checkbox label="The flow of information makes sense when navigating." description="Assistive technology like screen readers navigate the page in DOM order. If you used CSS to visually reposition elements, they might be announced in a nonsensical sequence. Instead, if you need something to appear earlier in the page, try to physically move it earlier in the DOM.
+" id="general-criteria-5b" /></>} id="general-criteria-5" />
 
 ### Accessibility points
 
-<label><input type="checkbox" /> **Structure:** The visual information architecture should map to the various rotor menus that exist by default. </label><br />
-- <label><input type="checkbox" /> **Check rotor:** Are there good headings, landmarks, links, form controls, and other elements? Do they make sense, and are they descriptive without overloading information? </label><br />
-  - <label><input type="checkbox" /> Headings: Check that heading levels convey structure/content and do not skip. A common practice is to use a single h1 for the primary headline or logo on a page, h2s for designating major sections, and h3s for supporting sections. </label><br />
-  - <label><input type="checkbox" /> Links </label><br />
-  - <label><input type="checkbox" /> Form controls </label><br />
-  - <label><input type="checkbox" /> Landmarks </label><br />
-  - <label><input type="checkbox" /> Tables </label><br />
+<checkbox label="Structure: The visual information architecture should map to the various rotor menus that exist by default." id="general-criteria-7" /><br />
+- <checkbox label="Check rotor: Are there good headings, landmarks, links, form controls, and other elements? Do they make sense, and are they descriptive without overloading information?" id="general-criteria-8" /><br />
+  - <checkbox label="Headings: Check that heading levels convey structure/content and do not skip. A common practice is to use a single h1 for the primary headline or logo on a page, h2s for designating major sections, and h3s for supporting sections." id="general-criteria-9" /><br />
+  - <checkbox label="Links" id="general-criteria-10" /><br />
+  - <checkbox label="Form controls" id="general-criteria-11" /><br />
+  - <checkbox label="Landmarks" id="general-criteria-12" /><br />
+  - <checkbox label="Tables" id="general-criteria-13" /><br />
 
 
-<label><input type="checkbox" /> **Labels:**</label>
-- <label><input type="checkbox" /> **Links:** Labels should be unique unless they have the same URL. They should be descriptive and informative.</label>
-- <label><input type="checkbox" /> **Buttons and form controls:**</label>
+<checkbox label="Labels:" id="general-criteria-14" />
+- <checkbox label="Links: Labels should be unique unless they have the same URL. They should be descriptive and informative." id="general-criteria-1" />
+- <checkbox label="Buttons and form controls:" id="general-criteria-15" />
   - Confirm that all form controls have effective labels. (Remember that there is a difference between being accessible and having a *good*, accessible experience. Clear, descriptive labels help create a better experience.)
   - **Expandable buttons:** There should be some indication that a button has the expandable control.
-- <label><input type="checkbox" /> **Form inputs:** These inputs should have a label — even if it's not visible.</label>
-- <label><input type="checkbox" /> **Icons**: Even if you don’t visibly see text, there should still be some kind of text for screen readers.</label>
-- <label><input type="checkbox" /> **Images**: Check all images for proper alt text. The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string: `alt=””`.</label>
-- <label><input type="checkbox" /> **Landmarks:** Landmark regions should have labels when there is more than one type of landmark and they are not the same (such as navigation, main, form, etc.).
-Section element shouldn’t be used unless it has a label.</label>
-- <label><input type="checkbox" /> **Tables**: Can you tell what the table is and what’s in it? [WebAIM has additional guidance on this.](https://webaim.org/techniques/tables/)</label>
-- <label><input type="checkbox" /> **Aria**: If there is visible text then there doesn’t need to be an `aria-label`. Aria provides more descriptive details to screen reader users. It doesn’t have to reiterate or override what might already be there so you should check that your aria is useful.</label>
+- <checkbox label="Form inputs: These inputs should have a label — even if it's not visible." id="general-criteria-16" />
+- <checkbox label="Icons: Even if you don’t visibly see text, there should still be some kind of text for screen readers." id="general-criteria-17" />
+- <checkbox label="Images: Check all images for proper alt text. The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string: `alt=””`." id="general-criteria-18" />
+- <checkbox label="Landmarks: Landmark regions should have labels when there is more than one type of landmark and they are not the same (such as navigation, main, form, etc.).
+Section element shouldn’t be used unless it has a label." id="general-criteria-19" />
+- <checkbox label="Tables: Can you tell what the table is and what’s in it? [WebAIM has additional guidance on this.](https://webaim.org/techniques/tables/)" id="general-criteria-20" />
+- <checkbox label="Aria: If there is visible text then there doesn’t need to be an `aria-label`. Aria provides more descriptive details to screen reader users. It doesn’t have to reiterate or override what might already be there so you should check that your aria is useful." id="general-criteria-21" />
   - It’s important to understand that ARIA can only affect the _semantics_ of an element; it has no effect on the _behavior_ of the element. For example, while you can hide an element from screen readers with `aria-hidden=”true”`, that does not change the focus behavior for that element. 

From 51d3a16f643f10ec6e4a8f6be9d9f510344293db Mon Sep 17 00:00:00 2001
From: Erin Donehoo <edonehoo@redhat.com>
Date: Thu, 26 Oct 2023 17:23:38 -0400
Subject: [PATCH 05/15] Works on checkboxes.

---
 .../accessibility-testing.md                  | 64 ++++++++++---------
 1 file changed, 35 insertions(+), 29 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 7f37417888..12de151a12 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -67,39 +67,45 @@ These are some of the main areas we check for on the PatternFly team to ensure t
 
 ### General criteria
 
-<Checkbox label="Rotor navigation can discover all information." id="general-criteria-1" /><br/>
+<Checkbox label="Rotor navigation can discover all information." id="general-criteria-1" /> 
 
-<Checkbox label="Shortcut navigation can discover all information."  description="For example, a keyboard shortcut that navigates between all headings on a page should discover all intended headings." /><br/>
+<Checkbox label="Shortcut navigation can discover all information."  description="For example, a keyboard shortcut that navigates between all headings on a page should discover all intended headings." id="general-criteria-2/>
 
-<Checkbox label="Cursor navigation can discover all applicable information." description="Some assistive technologies will have their own means of navigation and focus management. For example, VoiceOver uses a 'VO' key plus right or left arrow keys to navigate a page. This may be different than conventional keyboard navigation." id="general-criteria-3" /><br/>
+<Checkbox label="Cursor navigation can discover all applicable information." description="Some assistive technologies will have their own means of navigation and focus management. For example, VoiceOver uses a 'VO' key plus right or left arrow keys to navigate a page. This may be different than conventional keyboard navigation." id="general-criteria-3" />
 
-<Checkbox label="Keyboard navigation via the 'tab' key can discover all information. If content should be hidden from other assistive technology like a screen reader description="`className="ws-code">aria-hidden="true"</span>` should be passed to it." id="general-criteria-4" />
-- Unless content should be hidden from a screen reader (such as offscreen or presentational information) make sure that content is set to aria-hidden=”true”.  <br/>
+<Checkbox label={<span>Keyboard navigation via the <kbd>tab</kbd> key can discover all information.</span>} description={<span>If content should be hidden from other assistive technology like a screen reader, <span className="ws-code">aria-hidden="true"</span> should be passed instead.</span>} id="general-criteria-4" />
 
-<Checkbox label="Items are understandable and usable." body={<Checkbox label="When you navigate to an item by keyboard or other assistive technology, you should be able to easily understand and use the item." id="general-criteria-5a" /><Checkbox label="The flow of information makes sense when navigating." description="Assistive technology like screen readers navigate the page in DOM order. If you used CSS to visually reposition elements, they might be announced in a nonsensical sequence. Instead, if you need something to appear earlier in the page, try to physically move it earlier in the DOM.
-" id="general-criteria-5b" /></>} id="general-criteria-5" />
+<Checkbox label="Items are understandable and usable." body={<><Checkbox label="When you navigate to an item by keyboard or other assistive technology, you can easily understand and use the item." id="general-criteria-5a" /> <Checkbox label="The flow of information makes sense when navigating." description="Assistive technology (like screen readers) navigate the page in DOM order. If you use CSS to visually reposition elements, they may be announced in a nonsensical sequence. If you need something to appear earlier in the page, try to physically move it earlier in the DOM instead.
+" id="general-criteria-5b" /></>} id="general-criteria-5" /> <br/>
 
 ### Accessibility points
 
-<checkbox label="Structure: The visual information architecture should map to the various rotor menus that exist by default." id="general-criteria-7" /><br />
-- <checkbox label="Check rotor: Are there good headings, landmarks, links, form controls, and other elements? Do they make sense, and are they descriptive without overloading information?" id="general-criteria-8" /><br />
-  - <checkbox label="Headings: Check that heading levels convey structure/content and do not skip. A common practice is to use a single h1 for the primary headline or logo on a page, h2s for designating major sections, and h3s for supporting sections." id="general-criteria-9" /><br />
-  - <checkbox label="Links" id="general-criteria-10" /><br />
-  - <checkbox label="Form controls" id="general-criteria-11" /><br />
-  - <checkbox label="Landmarks" id="general-criteria-12" /><br />
-  - <checkbox label="Tables" id="general-criteria-13" /><br />
-
-
-<checkbox label="Labels:" id="general-criteria-14" />
-- <checkbox label="Links: Labels should be unique unless they have the same URL. They should be descriptive and informative." id="general-criteria-1" />
-- <checkbox label="Buttons and form controls:" id="general-criteria-15" />
-  - Confirm that all form controls have effective labels. (Remember that there is a difference between being accessible and having a *good*, accessible experience. Clear, descriptive labels help create a better experience.)
-  - **Expandable buttons:** There should be some indication that a button has the expandable control.
-- <checkbox label="Form inputs: These inputs should have a label — even if it's not visible." id="general-criteria-16" />
-- <checkbox label="Icons: Even if you don’t visibly see text, there should still be some kind of text for screen readers." id="general-criteria-17" />
-- <checkbox label="Images: Check all images for proper alt text. The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string: `alt=””`." id="general-criteria-18" />
-- <checkbox label="Landmarks: Landmark regions should have labels when there is more than one type of landmark and they are not the same (such as navigation, main, form, etc.).
-Section element shouldn’t be used unless it has a label." id="general-criteria-19" />
-- <checkbox label="Tables: Can you tell what the table is and what’s in it? [WebAIM has additional guidance on this.](https://webaim.org/techniques/tables/)" id="general-criteria-20" />
-- <checkbox label="Aria: If there is visible text then there doesn’t need to be an `aria-label`. Aria provides more descriptive details to screen reader users. It doesn’t have to reiterate or override what might already be there so you should check that your aria is useful." id="general-criteria-21" />
-  - It’s important to understand that ARIA can only affect the _semantics_ of an element; it has no effect on the _behavior_ of the element. For example, while you can hide an element from screen readers with `aria-hidden=”true”`, that does not change the focus behavior for that element. 
+<Checkbox label={<span> <b> Structure: </b> The visual information architecture should map to the various rotor menus that exist by default.</span>} body={<><Checkbox label="Check rotor for descriptive and concise headings, landmarks, links, form controls, tables, and other elements." id="accessibility-points-7a" />
+<Checkbox label="Heading levels convey structure/content and do not skip levels." description="A common practice is to use a single h1 for the primary headline or logo on a page, h2s for designating major sections, and h3s for supporting sections." id="accessibility-points-7b" />
+<Checkbox label="Landmarks" id="accessibility-points-7c" />
+<Checkbox label="Links" id="accessibility-points-7d" />
+<Checkbox label="Form controls" id="accessibility-points-7e" />
+<Checkbox label="Tables" id="accessibility-points-7f" /></>}  id="accessibility-points-7" />
+<br/>
+<Checkbox label={<span> <b> Labels: </b> </span>} body={<><Checkbox label=<span><b>Link</b> labels  are descriptive, informative, and unique (unless they have the same URL).</span> id="accessibility-points-8a"/> 
+
+  <Checkbox label={<span><b>Buttons and form controls:</b></span>} description={ <span>
+    <li> All form controls have clear and descriptive labels. </li>
+    <li> Indicate that a button has the expandable control. </li>
+  </span>
+  }
+  id="general-criteria-8b" />
+    
+    <Checkbox label={<span><b>Form inputs</b> have a label — even if it's not visible.</span>} id="general-criteria-8c" />
+    
+    <Checkbox label={<span><b>Icons</b> have some some kind of text for screen readers - even if it's not visible.</span>} id="general-criteria-8d" />
+
+    <Checkbox label={<span><b>Images have proper alt text.</b></span>} description="The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string: `alt=””`." id="general-criteria-8e" />
+
+    <Checkbox label={<span> <b>Landmark</b> regions should have labels when there is more than one type of landmark, and they are not the same (such as navigation, main, form, etc.). Section element shouldn’t be used unless it has a label.</span>} id="general-criteria-8f" />
+
+    <Checkbox label={<span><b>Tables</b> and table content is clearly described. <a href="https://webaim.org/techniques/tables/">WebAIM has additional guidance on this.</a></span>} id="general-criteria-8g" />
+
+    <Checkbox label={<span><b>Aria</b> provides descriptive details to screen reader users, without reiterating or overriding the text that is already there. If there is visible text then there doesn’t need to be an <span className="ws-code">aria-label</span>. </span>} description={<span>It’s important to understand that ARIA can only affect the semantics of an element; not the behavior. For example, while you can hide an element from screen readers with <span> className="ws-code">aria-hidden=”true”</span>, that does not change the focus behavior for that element.</span>} id="general-criteria-8h" />
+
+</>}  id="general-criteria-8" />

From 2003d3e9e74247799eead1d61a48c29915928e52 Mon Sep 17 00:00:00 2001
From: Erin Donehoo <edonehoo@redhat.com>
Date: Fri, 27 Oct 2023 10:55:16 -0400
Subject: [PATCH 06/15] Resolves merge conflict.

---
 .../developer-resources/accessibility-testing.md     | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 12de151a12..8009e0668c 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -28,7 +28,7 @@ There are many tools you can use to validate your HTML, such as [W3C’s markup
  
 We also offer the [patternfly-a11y script](https://github.com/patternfly/patternfly-a11y) for bulk testing that reports any aXe accessibility violations from a set of pages. To use this script, a configuration file can be set to adapt our script to your specific needs like authentication, waiting for any specific items to finish loading (like a loading spinner), etc. 
  
- When used as a report, it will give an [accessibility report via surge](http://a11y-os.surge.sh/). The UI should be built first in the CI workflow and then a job created to run the a11y script against that build. The a11y script assumes that there is a web server running somewhere that is serving up the pages  that it can reach. (for example, in localhost:8000). If you want to test a step before deployment, you could follow the path of integrating aXe with [Cypress](https://www.cypress.io/).
+When used as a report, it will give an [accessibility report via surge](http://a11y-os.surge.sh/). The UI should be built first in the CI workflow and then a job created to run the a11y script against that build. The a11y script assumes that there is a web server running somewhere that is serving up the pages (for example, in `localhost:8000`) that it can reach. If you want to test a step before deployment, you could follow the path of integrating aXe with Cypress.
 
 
 ### Test keyboard accessibility
@@ -69,18 +69,18 @@ These are some of the main areas we check for on the PatternFly team to ensure t
 
 <Checkbox label="Rotor navigation can discover all information." id="general-criteria-1" /> 
 
-<Checkbox label="Shortcut navigation can discover all information."  description="For example, a keyboard shortcut that navigates between all headings on a page should discover all intended headings." id="general-criteria-2/>
+<Checkbox label="Shortcut navigation can discover all information."  description="For example, a keyboard shortcut that navigates between all headings on a page should discover all intended headings." id="general-criteria-2" />
 
 <Checkbox label="Cursor navigation can discover all applicable information." description="Some assistive technologies will have their own means of navigation and focus management. For example, VoiceOver uses a 'VO' key plus right or left arrow keys to navigate a page. This may be different than conventional keyboard navigation." id="general-criteria-3" />
 
 <Checkbox label={<span>Keyboard navigation via the <kbd>tab</kbd> key can discover all information.</span>} description={<span>If content should be hidden from other assistive technology like a screen reader, <span className="ws-code">aria-hidden="true"</span> should be passed instead.</span>} id="general-criteria-4" />
 
-<Checkbox label="Items are understandable and usable." body={<><Checkbox label="When you navigate to an item by keyboard or other assistive technology, you can easily understand and use the item." id="general-criteria-5a" /> <Checkbox label="The flow of information makes sense when navigating." description="Assistive technology (like screen readers) navigate the page in DOM order. If you use CSS to visually reposition elements, they may be announced in a nonsensical sequence. If you need something to appear earlier in the page, try to physically move it earlier in the DOM instead.
+<Checkbox label="UI elements are understandable and usable." body={<><Checkbox label="When you navigate to an element by keyboard or other assistive technology, you can easily understand and use the item." id="general-criteria-5a" /> <Checkbox label="The flow of information makes sense when navigating." description="Assistive technology (like screen readers) navigate the page in DOM order. If you use CSS to visually reposition elements, they may be announced in a nonsensical sequence. If you need something to appear earlier in the page, try to physically move it earlier in the DOM instead.
 " id="general-criteria-5b" /></>} id="general-criteria-5" /> <br/>
 
 ### Accessibility points
 
-<Checkbox label={<span> <b> Structure: </b> The visual information architecture should map to the various rotor menus that exist by default.</span>} body={<><Checkbox label="Check rotor for descriptive and concise headings, landmarks, links, form controls, tables, and other elements." id="accessibility-points-7a" />
+<Checkbox label={<span> <b> Structure: </b> The visual information architecture maps to the various rotor menus that exist by default.</span>} body={<><Checkbox label="Rotor has descriptive and concise headings, landmarks, links, form controls, tables, and other elements." id="accessibility-points-7a" />
 <Checkbox label="Heading levels convey structure/content and do not skip levels." description="A common practice is to use a single h1 for the primary headline or logo on a page, h2s for designating major sections, and h3s for supporting sections." id="accessibility-points-7b" />
 <Checkbox label="Landmarks" id="accessibility-points-7c" />
 <Checkbox label="Links" id="accessibility-points-7d" />
@@ -96,9 +96,9 @@ These are some of the main areas we check for on the PatternFly team to ensure t
   }
   id="general-criteria-8b" />
     
-    <Checkbox label={<span><b>Form inputs</b> have a label — even if it's not visible.</span>} id="general-criteria-8c" />
+    <Checkbox label={<span><b>Form inputs</b> have a label (even if it's not visible).</span>} id="general-criteria-8c" />
     
-    <Checkbox label={<span><b>Icons</b> have some some kind of text for screen readers - even if it's not visible.</span>} id="general-criteria-8d" />
+    <Checkbox label={<span><b>Icons</b> have some some kind of text for screen readers (even if it's not visible.)</span>} id="general-criteria-8d" />
 
     <Checkbox label={<span><b>Images have proper alt text.</b></span>} description="The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string: `alt=””`." id="general-criteria-8e" />
 

From 29d4753fcc849c7ca2218bdc194cf0a6fd4bef53 Mon Sep 17 00:00:00 2001
From: Erin Donehoo <105813956+edonehoo@users.noreply.github.com>
Date: Tue, 31 Oct 2023 10:55:10 -0400
Subject: [PATCH 07/15] Update
 packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md

---
 .../content/developer-resources/accessibility-testing.md        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 8009e0668c..19e2054ae3 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -63,7 +63,7 @@ Colors should pass the following contrast checks, to ensure that users across th
 
 We recommend referencing the following checklist as you assess your product's accessibility.
 
-These are some of the main areas we check for on the PatternFly team to ensure that components meet consistent accessibility standards, but, to check your complete implementation, we recommend checking these same areas in your products. 
+These are some of the main areas we check for on the PatternFly team to ensure that a UI meets consistent accessibility standards. To assess your specific implementation, we recommend checking these same areas in your product. 
 
 ### General criteria
 

From c212ec56f6bf27c4c828ec9590a822acec7dcb5c Mon Sep 17 00:00:00 2001
From: Erin Donehoo <105813956+edonehoo@users.noreply.github.com>
Date: Mon, 4 Dec 2023 15:46:32 -0500
Subject: [PATCH 08/15] Update
 packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md

Co-authored-by: Eric Olkowski <70952936+thatblindgeye@users.noreply.github.com>
---
 .../content/developer-resources/accessibility-testing.md        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 19e2054ae3..5186129be1 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -104,7 +104,7 @@ These are some of the main areas we check for on the PatternFly team to ensure t
 
     <Checkbox label={<span> <b>Landmark</b> regions should have labels when there is more than one type of landmark, and they are not the same (such as navigation, main, form, etc.). Section element shouldn’t be used unless it has a label.</span>} id="general-criteria-8f" />
 
-    <Checkbox label={<span><b>Tables</b> and table content is clearly described. <a href="https://webaim.org/techniques/tables/">WebAIM has additional guidance on this.</a></span>} id="general-criteria-8g" />
+    <Checkbox label={<span><b>Tables</b> and table content is clearly described. WebAIM has additional guidance on <a href="https://webaim.org/techniques/tables/">creating accessible tables</a>.</span>} id="general-criteria-8g" />
 
     <Checkbox label={<span><b>Aria</b> provides descriptive details to screen reader users, without reiterating or overriding the text that is already there. If there is visible text then there doesn’t need to be an <span className="ws-code">aria-label</span>. </span>} description={<span>It’s important to understand that ARIA can only affect the semantics of an element; not the behavior. For example, while you can hide an element from screen readers with <span> className="ws-code">aria-hidden=”true”</span>, that does not change the focus behavior for that element.</span>} id="general-criteria-8h" />
 

From 643b38baeee88d103b0497b8b11d87f053624360 Mon Sep 17 00:00:00 2001
From: Erin Donehoo <105813956+edonehoo@users.noreply.github.com>
Date: Mon, 4 Dec 2023 15:46:40 -0500
Subject: [PATCH 09/15] Update
 packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md

Co-authored-by: Eric Olkowski <70952936+thatblindgeye@users.noreply.github.com>
---
 .../content/developer-resources/accessibility-testing.md        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 5186129be1..fc28296bf3 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -100,7 +100,7 @@ These are some of the main areas we check for on the PatternFly team to ensure t
     
     <Checkbox label={<span><b>Icons</b> have some some kind of text for screen readers (even if it's not visible.)</span>} id="general-criteria-8d" />
 
-    <Checkbox label={<span><b>Images have proper alt text.</b></span>} description="The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string: `alt=””`." id="general-criteria-8e" />
+    <Checkbox label={<span><b>Images have proper alt text.</b></span>} description={<span>The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string: <code className="ws-code">alt=""</code></span>}  id="general-criteria-8e" />
 
     <Checkbox label={<span> <b>Landmark</b> regions should have labels when there is more than one type of landmark, and they are not the same (such as navigation, main, form, etc.). Section element shouldn’t be used unless it has a label.</span>} id="general-criteria-8f" />
 

From fcc4cffb0613a413b940fd16f3a8da03ff51169e Mon Sep 17 00:00:00 2001
From: Erin Donehoo <edonehoo@redhat.com>
Date: Tue, 5 Dec 2023 17:53:23 -0500
Subject: [PATCH 10/15] Content alterations.

---
 .../accessibility-testing.md                  | 43 ++++++++++---------
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index fc28296bf3..542e4b3318 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -6,64 +6,65 @@ import { Checkbox } from '@patternfly/react-core';
 
 # Testing your product's accessibility 
 
-This guide contains instructions and recommendations to comprehensively test your product's accessibility to identify accessibility issues and opportunities for improvement.  
+This guide contains instructions and recommendations that you can use to robustly test your product's accessibility, in order to identify accessibility issues and opportunities for improvement.  
 
 **Keep in mind that this guide will not cover every scenario.**
 
-## General testing recommendations 
+## Standard testing procedures 
 
-Many accessibility issues can be found by doing a few simple checks: 
+Many accessibility issues can be found by doing a few standard checks. 
 
 ### Validate your HTML
 
 Good accessibility practices start with structural, semantic HTML. When a screen reader (or any sort of assistive technology) scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page. No styles or JavaScript will be read by a screen reader. 
 
-Screen readers like Voice Over (VO), NVDA, or JAWS don't just turn text into speech. They use information in the HTML to list all of the headings on a page, give extra navigation controls to data tables, announce how many items are in a list, and more. This makes semantic HTML essential. 
+Screen readers (like Voice Over (VO), NVDA, or JAWS) don't just turn text into speech. They also use information in the HTML to list all of the headings on a page, give extra navigation controls to data tables, announce how many items are in a list, and more. This makes semantic HTML essential. 
 
-There are many tools you can use to validate your HTML, such as [W3C’s markup validation service](https://validator.w3.org/). 
+You can use an HTML validation tool to test your product, such as [W3C’s markup validation service](https://validator.w3.org/). 
 
 ### Check for accessibility violations with an audit tool
 
- If you are using PatternFly, we recommend using aXe: The Accessibility Engine (using their [DevTools](https://www.deque.com/axe/devtools/) or the [Chrome](https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd) or [Firefox](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/) extension) to check for accessibility violations locally. 
+When using PatternFly, we recommend checking for accessibility violations locally via aXe: The Accessibility Engine (using [aXe DevTools](https://www.deque.com/axe/devtools/), the [Chrome extension](https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd), or the [Firefox extension](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/)). If you want to test prior to deployment, you can integrate aXe with [Cypress](https://www.cypress.io/).
  
-We also offer the [patternfly-a11y script](https://github.com/patternfly/patternfly-a11y) for bulk testing that reports any aXe accessibility violations from a set of pages. To use this script, a configuration file can be set to adapt our script to your specific needs like authentication, waiting for any specific items to finish loading (like a loading spinner), etc. 
- 
-When used as a report, it will give an [accessibility report via surge](http://a11y-os.surge.sh/). The UI should be built first in the CI workflow and then a job created to run the a11y script against that build. The a11y script assumes that there is a web server running somewhere that is serving up the pages (for example, in `localhost:8000`) that it can reach. If you want to test a step before deployment, you could follow the path of integrating aXe with Cypress.
+#### Bulk testing with the patternfly-ally script
+
+We offer the [patternfly-a11y script](https://github.com/patternfly/patternfly-a11y) for bulk testing, which reports any aXe accessibility violations from a set of pages. You can adapt this script to your needs by creating a configuration file that includes authentication, waits for specific items to finish loading (like a loading spinner), or addresses other items relevant to your use case. As a report, this script will deliver an [accessibility report via surge](http://a11y-os.surge.sh/). 
 
+Before using this script, your UI should be built in the CI workflow. Once built, create a job to run the script against that build. The script assumes that a web server is running and serving your product somewhere that the script can reach (for example, in `localhost:8000`). 
 
 ### Test keyboard accessibility
 
 The keyboard is an essential accessibility tool, so it is necessary to ensure that the following requirements are met: 
 
-  - All functionality is keyboard accessible.
-  - Elements in the HTML and in the layout follow a logical order.
-  - Elements with focus are clearly visible.
+- All functionality is keyboard accessible.
+- Elements in the HTML and in the layout follow a logical order.
+- Elements with focus are clearly visible.
 
 ### Test without styles
 
-Because screen readers cannot access style information, you should disable styles for your product and ensure that your information architecture is effective and that there are adequate text labels.
+Screen readers cannot access style information, so you should disable styles for your product to test that your information architecture is effective and that elements have adequate text labels.
 
- The [WAVE browser extension from WebAIM](//wave.webaim.org/extension/) provides this feature if it isn't available in the browser you are using.
+The [WAVE browser extension from WebAIM](/wave.webaim.org/extension/) allows you to disable styles if this isn't available in the browser you are using.
 
 ### Test with a screen reader 
 
-You can use any screen reader that is available in your operating system. To test PatternFly, we target the following screen readers:
-  - [JAWS](https://www.freedomscientific.com/products/software/jaws/) with Chrome, Windows ([JAWS keyboard shortcuts](//dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts))
-  - [Voiceover](https://support.apple.com/guide/voiceover/welcome/mac) with Safari, Mac ([Voiceover keyboard shortcuts](//dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts))
-  - [NVDA](https://www.nvaccess.org/download/) with Firefox, Windows ([NVDA keyboard shortcuts](//dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts))
+You can test with any screen reader that is available in your operating system. In PatternFly, we target:
+  - [JAWS](https://www.freedomscientific.com/products/software/jaws/) with Chrome, Windows ([JAWS keyboard shortcuts](//dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts)).
+  - [VoiceOver](https://support.apple.com/guide/voiceover/welcome/mac) with Safari, Mac ([VoiceOver keyboard shortcuts](//dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts)).
+  - [NVDA](https://www.nvaccess.org/download/) with Firefox, Windows ([NVDA keyboard shortcuts](//dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts)).
 
 ### Check color contrast
 
-Colors should pass the following contrast checks, to ensure that users across the vision spectrum can understand your product:
+Your UI's colors should pass the following contrast checks to ensure that users across the vision spectrum can understand your product:
     - Text color against background color ([Understanding WCAG 1.4.3](//www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html))
     - Text color against link color ([Technique G183](//www.w3.org/TR/WCAG20-TECHS/G183.html))
     - Visible boundaries of buttons and form elements against adjacent background color ([Understanding WCAG 1.4.11](//www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html))
 
 ## Accessibility testing checklist
 
-We recommend referencing the following checklist as you assess your product's accessibility.
+To keep track of your testing efforts, we recommend referencing the following checklist.
 
-These are some of the main areas we check for on the PatternFly team to ensure that a UI meets consistent accessibility standards. To assess your specific implementation, we recommend checking these same areas in your product. 
+This checklist includes some of the main areas that the PatternFly team checks for to ensure that a UI meets consistent accessibility standards. To evaluate your specific implementation, we recommend checking these same areas in your product. 
 
 ### General criteria
 

From bcd2f3ec23698075c16787fca636cb242c885011 Mon Sep 17 00:00:00 2001
From: Erin Donehoo <edonehoo@redhat.com>
Date: Wed, 6 Dec 2023 11:14:37 -0500
Subject: [PATCH 11/15] Content changes from review feedback.

---
 .../developer-resources/accessibility-testing.md  | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 542e4b3318..38af84b4e7 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -66,7 +66,7 @@ To keep track of your testing efforts, we recommend referencing the following ch
 
 This checklist includes some of the main areas that the PatternFly team checks for to ensure that a UI meets consistent accessibility standards. To evaluate your specific implementation, we recommend checking these same areas in your product. 
 
-### General criteria
+### Broad accessibility criteria
 
 <Checkbox label="Rotor navigation can discover all information." id="general-criteria-1" /> 
 
@@ -79,7 +79,7 @@ This checklist includes some of the main areas that the PatternFly team checks f
 <Checkbox label="UI elements are understandable and usable." body={<><Checkbox label="When you navigate to an element by keyboard or other assistive technology, you can easily understand and use the item." id="general-criteria-5a" /> <Checkbox label="The flow of information makes sense when navigating." description="Assistive technology (like screen readers) navigate the page in DOM order. If you use CSS to visually reposition elements, they may be announced in a nonsensical sequence. If you need something to appear earlier in the page, try to physically move it earlier in the DOM instead.
 " id="general-criteria-5b" /></>} id="general-criteria-5" /> <br/>
 
-### Accessibility points
+### Structural accessibility criteria
 
 <Checkbox label={<span> <b> Structure: </b> The visual information architecture maps to the various rotor menus that exist by default.</span>} body={<><Checkbox label="Rotor has descriptive and concise headings, landmarks, links, form controls, tables, and other elements." id="accessibility-points-7a" />
 <Checkbox label="Heading levels convey structure/content and do not skip levels." description="A common practice is to use a single h1 for the primary headline or logo on a page, h2s for designating major sections, and h3s for supporting sections." id="accessibility-points-7b" />
@@ -92,7 +92,7 @@ This checklist includes some of the main areas that the PatternFly team checks f
 
   <Checkbox label={<span><b>Buttons and form controls:</b></span>} description={ <span>
     <li> All form controls have clear and descriptive labels. </li>
-    <li> Indicate that a button has the expandable control. </li>
+    <li> Expandable buttons display the expandable control and utilize <code className="ws-code">aria-expanded</code> to indicate that a button is expandable. </li>
   </span>
   }
   id="general-criteria-8b" />
@@ -107,6 +107,13 @@ This checklist includes some of the main areas that the PatternFly team checks f
 
     <Checkbox label={<span><b>Tables</b> and table content is clearly described. WebAIM has additional guidance on <a href="https://webaim.org/techniques/tables/">creating accessible tables</a>.</span>} id="general-criteria-8g" />
 
-    <Checkbox label={<span><b>Aria</b> provides descriptive details to screen reader users, without reiterating or overriding the text that is already there. If there is visible text then there doesn’t need to be an <span className="ws-code">aria-label</span>. </span>} description={<span>It’s important to understand that ARIA can only affect the semantics of an element; not the behavior. For example, while you can hide an element from screen readers with <span> className="ws-code">aria-hidden=”true”</span>, that does not change the focus behavior for that element.</span>} id="general-criteria-8h" />
+    <Checkbox label={<span><b>ARIA</b> labels provide descriptive details to screen reader users, without reiterating or overriding the text that is already there. If there is visible text then there doesn’t need to be an ARIA label. </span>} 
+    description={ <span>
+      <li> To add a non-visual label to an element you should use <span className="ws-code">aria-label</span>. Keep in mind you should not add this to an element that already has a visual label in the UI. You can also use <span className="ws-code">aria-labelledby</span> to label an element through existing text or <span className="ws-code">aria-label</span>. </li>
+      <li> <span> It’s important to understand that ARIA can only affect the semantics of an element; not the behavior. For example, while you can hide an element from screen readers with <span className="ws-code">aria-hidden=”true”</span>, that does not change the focus behavior for that element.</span></li>
+    </span>
+    }
+    
+    id="general-criteria-8h" />
 
 </>}  id="general-criteria-8" />

From 8e4edbf9b04882ccc07663d37f32560bc8f42e5f Mon Sep 17 00:00:00 2001
From: Erin Donehoo <edonehoo@redhat.com>
Date: Wed, 6 Dec 2023 15:52:19 -0500
Subject: [PATCH 12/15] Updates to buttons point.

---
 .../content/developer-resources/accessibility-testing.md        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index 38af84b4e7..a71819bd91 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -92,7 +92,7 @@ This checklist includes some of the main areas that the PatternFly team checks f
 
   <Checkbox label={<span><b>Buttons and form controls:</b></span>} description={ <span>
     <li> All form controls have clear and descriptive labels. </li>
-    <li> Expandable buttons display the expandable control and utilize <code className="ws-code">aria-expanded</code> to indicate that a button is expandable. </li>
+    <li> Expandable buttons display the expandable control and utilize <code className="ws-code">aria-expanded</code> to indicate that a button is expandable. <code className="ws-code">aria-expanded</code> should always have a boolean value if a button is meant to be expandable. </li>
   </span>
   }
   id="general-criteria-8b" />

From 3f86f3636e4a785869cadc303343f38d4ec2a37c Mon Sep 17 00:00:00 2001
From: Erin Donehoo <edonehoo@redhat.com>
Date: Mon, 11 Dec 2023 10:55:44 -0500
Subject: [PATCH 13/15] Grammar and typo updates.

---
 .../content/developer-resources/accessibility-testing.md      | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index a71819bd91..eaab52e6cb 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -72,7 +72,7 @@ This checklist includes some of the main areas that the PatternFly team checks f
 
 <Checkbox label="Shortcut navigation can discover all information."  description="For example, a keyboard shortcut that navigates between all headings on a page should discover all intended headings." id="general-criteria-2" />
 
-<Checkbox label="Cursor navigation can discover all applicable information." description="Some assistive technologies will have their own means of navigation and focus management. For example, VoiceOver uses a 'VO' key plus right or left arrow keys to navigate a page. This may be different than conventional keyboard navigation." id="general-criteria-3" />
+<Checkbox label="Cursor navigation can discover all applicable information." description="Some assistive technologies will have their own means of navigation and focus management. For example, VoiceOver uses a 'VO' key plus right or left arrow keys to navigate a page. This may be different from conventional keyboard navigation." id="general-criteria-3" />
 
 <Checkbox label={<span>Keyboard navigation via the <kbd>tab</kbd> key can discover all information.</span>} description={<span>If content should be hidden from other assistive technology like a screen reader, <span className="ws-code">aria-hidden="true"</span> should be passed instead.</span>} id="general-criteria-4" />
 
@@ -99,7 +99,7 @@ This checklist includes some of the main areas that the PatternFly team checks f
     
     <Checkbox label={<span><b>Form inputs</b> have a label (even if it's not visible).</span>} id="general-criteria-8c" />
     
-    <Checkbox label={<span><b>Icons</b> have some some kind of text for screen readers (even if it's not visible.)</span>} id="general-criteria-8d" />
+    <Checkbox label={<span><b>Icons</b> have some kind of text for screen readers (even if it's not visible.)</span>} id="general-criteria-8d" />
 
     <Checkbox label={<span><b>Images have proper alt text.</b></span>} description={<span>The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string: <code className="ws-code">alt=""</code></span>}  id="general-criteria-8e" />
 

From 83b658a53b55ba2d86cebcca67c80ef5d47ac15a Mon Sep 17 00:00:00 2001
From: Erin Donehoo <105813956+edonehoo@users.noreply.github.com>
Date: Fri, 5 Jan 2024 10:21:14 -0500
Subject: [PATCH 14/15] Update
 packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md

Co-authored-by: Eric Olkowski <70952936+thatblindgeye@users.noreply.github.com>
---
 .../content/developer-resources/accessibility-testing.md        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index eaab52e6cb..de98f910df 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -109,7 +109,7 @@ This checklist includes some of the main areas that the PatternFly team checks f
 
     <Checkbox label={<span><b>ARIA</b> labels provide descriptive details to screen reader users, without reiterating or overriding the text that is already there. If there is visible text then there doesn’t need to be an ARIA label. </span>} 
     description={ <span>
-      <li> To add a non-visual label to an element you should use <span className="ws-code">aria-label</span>. Keep in mind you should not add this to an element that already has a visual label in the UI. You can also use <span className="ws-code">aria-labelledby</span> to label an element through existing text or <span className="ws-code">aria-label</span>. </li>
+      <li> To add a non-visual label to an element you should use <span className="ws-code">aria-label</span>. You can also use <span className="ws-code">aria-labelledby</span> to label one element with another element's existing text or <span className="ws-code">aria-label</span>. </li>
       <li> <span> It’s important to understand that ARIA can only affect the semantics of an element; not the behavior. For example, while you can hide an element from screen readers with <span className="ws-code">aria-hidden=”true”</span>, that does not change the focus behavior for that element.</span></li>
     </span>
     }

From 16d508dd684d4545f11cc4221ecb8523e87c30b6 Mon Sep 17 00:00:00 2001
From: Erin Donehoo <edonehoo@redhat.com>
Date: Mon, 8 Jan 2024 10:22:54 -0500
Subject: [PATCH 15/15] Merging.

---
 .../content/developer-resources/accessibility-testing.md | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
index de98f910df..860f128c01 100644
--- a/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
+++ b/packages/documentation-site/patternfly-docs/content/developer-resources/accessibility-testing.md
@@ -107,13 +107,6 @@ This checklist includes some of the main areas that the PatternFly team checks f
 
     <Checkbox label={<span><b>Tables</b> and table content is clearly described. WebAIM has additional guidance on <a href="https://webaim.org/techniques/tables/">creating accessible tables</a>.</span>} id="general-criteria-8g" />
 
-    <Checkbox label={<span><b>ARIA</b> labels provide descriptive details to screen reader users, without reiterating or overriding the text that is already there. If there is visible text then there doesn’t need to be an ARIA label. </span>} 
-    description={ <span>
-      <li> To add a non-visual label to an element you should use <span className="ws-code">aria-label</span>. You can also use <span className="ws-code">aria-labelledby</span> to label one element with another element's existing text or <span className="ws-code">aria-label</span>. </li>
-      <li> <span> It’s important to understand that ARIA can only affect the semantics of an element; not the behavior. For example, while you can hide an element from screen readers with <span className="ws-code">aria-hidden=”true”</span>, that does not change the focus behavior for that element.</span></li>
-    </span>
-    }
-    
-    id="general-criteria-8h" />
+    <Checkbox label={<span><b>ARIA</b> labels provide descriptive details to screen reader users, without reiterating or overriding the text that is already there. If there is visible text then there doesn’t need to be an ARIA label. </span>} id="general-criteria-8h" />
 
 </>}  id="general-criteria-8" />