🇺🇸United States @katannshaw

volkswagenchick → credited katannshaw → .

I've tested it using Apple VoiceOver, ARC Toolkit, and axe DevTools and everything looked good regarding the two reported issues:

1. aXe rule: button-name - Buttons must have discernible text - In element: .toolbar-button--icon--dots
2. aXe rule: region - All page content should be contained by landmarks - In element: .top-bar__context

I reviewed the code as well, and it all appeared to be set up properly from an accessibility perspective. The `` landmark is set up properly and didn't throw any errors with the automated checkers.

I did find one related issue when testing with the screen reader that needs to be resolved with this module or the main Navigation module itself.

• The "Edit" button is read aloud as "Ed Edit" to screen readers
• This is because there's an icon that's no needed for the button as it's purely decorative
• I recommend removing the altogether

It appears to me that the changes in commit b99b9552 and commit d68ff2c9 are causing a11y issues because when there’s more than one menu on the page, each nav needs to have a unique label per WCAG 2.2 1.3.1: Info and Relationships (Level A) and 4.1.2: Name, Role, Value (Level A)

I'm also seeing a related accessibility issues in that each menu should contain a wrapping <nav> element

The unique aria-labelledby attribute should be added to the <nav> element instead of the <ul> element. Per W3C ARIA Landmark Example > Navigation Landmark, here is how a menu should be rendered when there's more than one menu on the page:

<nav aria-labelledby="nav1">
  <h2 id="nav1">Title for navigation 1<h2>
  <ul>
    <li><a href="page11.html">Link 1</a></li>
    <li><a href="page12.html">Link 2</a></li>
    .....
  </ul>
</nav>
<nav aria-labelledby="nav2">
  <h2 id="nav2">Title for navigation 2<h2>
  <ul>
    <li><a href="page11.html">Link 1</a></li>
    <li><a href="page12.html">Link 2</a></li>
    .....
  </ul>
</nav>

Other resources explaining this reasoning:

• ARIA Authoring Practices Guide (APG) > Landmark Regions
• W3C WAI > Menu Structure
• W3C WAI > Labeling Regions

Hope it helps.

katannshaw → created an issue.

After further checking, I can see that the page title is completely hidden from the <front> page in the block settings at /admin/structure/block/manage/drupal_cms_olivero_page_title?destination=/admin/structure/block

So I think the best high-level fix would be to:

1. Make the page title block required on every page
2. Make sure that its value matches the page title used within the <title></title> tag
3. When it is hidden on a page like the <front> page, add the .visually-hidden CSS class to properly hide it → from sighted users and let it get read aloud to screen readers
4. Do this all through the already-existing Blocks UI > Content Above > Page Title at /admin/structure/block/manage/drupal_cms_olivero_page_title?destination=/admin/structure/block

To fix this, we'll want to add the `.visually-hidden` CSS class to an H1 page title that's always on the page. Checking to see what's there now.

Hello! I want to propose the following:

1. I want to propose creating a new page titled “Our Adopted Accessibility Standards” (or something similar) containing a list from the External Accessibility Resources - General Resources → page. I think it would be a good addition.
2. I think that making the following updates to the  External Accessibility Resources →  would be good additions as well, but I have some questions:

• Is Drupal following the WCAG 2.1 or 2.2 standards?
  • If it's 2.2, I propose changing "WCAG 2.1 (includes WCAG 2.0) - www.w3.org/TR/WCAG21" to "WCAG 2.2, Level AA - https://www.w3.org/TR/WCAG22/"
• I propose changing "ARIA Authoring Practices Guide (APG) - https://www.w3.org/WAI/ARIA/apg/" to this
  • ARIA:
    • WAI-ARIA 1.2 - https://www.w3.org/WAI/standards-guidelines/aria/
    • ARIA Authoring Practices Guide (APG) - https://www.w3.org/WAI/ARIA/apg/
• Should these also be included for Drupal?
  • Section 508 (revised) - https://www.access-board.gov/ict/
  • International Web Accessibility Standards & Laws (We can use this site or create a new page similar to it  https://www.boia.org/blog/international-web-accessibility-laws-an-overview)

Thanks.

-- Kat

pameeela → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

Added "Related WCAG success criteria and techniques" to issue description to provide context and clarity.

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

+1 I totally support adding @e0ipso Mateu Aguiló Bosch as co-maintainer. He's done so much for the Drupal community.

volkswagenchick → credited katannshaw → .

I agree with mherchel → that when a user enters the mobile nav, keyboard focus must be trapped within it until the user:

* Selects the Close/OK/X button
* Selects the ESC key
* Clicks outside of the menu with their mouse

However I disagree on the WCAG success criteria that this violates. I believe that this violates 2.1.2 No Keyboard Trap (Level A). Under an example in this SC titled "A modal dialog box", it mentions:

A Web application brings up a dialog box. At the bottom of the dialog are two buttons, Cancel and OK. When the dialog has been opened, focus is trapped within the dialog; tabbing from the last control in the dialog takes focus to the first control in the dialog. The dialog is dismissed by activating the Cancel button or the OK button.

The WCAG 2.4.7 Focus Visible (Level AA) SC refers to the visible focus indicator for focusable elements.

I like Mike's idea.

Added link to Google sheet with WCAG 2.2 success criteria for reporting issues.

I'm also seeing three instances of these focusable yet visually-hidden headings.

<h4 id="menu--shortcuts--2" class="toolbar-block__title visually-hidden focusable"></h4>
<h4 id="menu--content" class="toolbar-block__title visually-hidden focusable"></h4>
<h4 id="menu--admin" class="toolbar-block__title visually-hidden focusable"></h4>

Because these are meant to be visually-hidden headings, I'd recommend the following proposed solution:

1. Add missing heading text for each of them
2. Remove the CSS class .focusable

<h4 id="menu--shortcuts--2" class="toolbar-block__title visually-hidden">Shortcuts</h4>
<h4 id="menu--content" class="toolbar-block__title visually-hidden">Content</h4>
<h4 id="menu--admin" class="toolbar-block__title visually-hidden">Administration</h4>

Added WCAG 2.2 success criteria.

Added WCAG 2.2 success criteria and moved steps to reproduce into its own section for easier readability.

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

laura.gates → credited katannshaw → .

katannshaw → created an issue.

ckrina → credited katannshaw → .

ckrina → credited katannshaw → .

ckrina → credited katannshaw → .

Updating summary to better reflect issue.

ckrina → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

katannshaw → created an issue.

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

katannshaw → created an issue.

volkswagenchick → credited katannshaw → .

Thanks for everything @webchick including helping me with my first contribution day years ago when I was super nervous. You helped to ease my worries with your sense of peace and total care. I will always be grateful for that.

volkswagenchick → credited katannshaw → .

katannshaw → created an issue.

katannshaw → created an issue.

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

volkswagenchick → credited katannshaw → .

nicxvan → credited katannshaw → .

katannshaw → created an issue.

nicxvan → credited katannshaw → .

nicxvan → credited katannshaw → .

volkswagenchick → credited katannshaw → .

katannshaw → created an issue.