Hiding the menu does not hide the menu in NVDA

Overview

I do not know your reporting format, but I will do my best to follow it

I opened this site for the first time. I am using the screen reader NVDA 2017.1 / Firefox 52.02. When I got to the menu, I toggled the un-labeled button to close the menu. However, while it was visually hidden the entire menu, including the collapse sub-sections, were still announced and still tab-stops.

Feature: Hide the menu from screen reader users when they toggle button to hide the menu.
  As an NVDA user…
  I want to reduce audio clutter by dismissing the menu…
  So that I can get to the content of the site.

  Scenario: Attempting to the use the site for the first time
    Given that I am an NVDA user,
    When I select the unlabeled toggle to close the navigation menu,
    Then I should no longer have the menu in my tab order for the page.

Other

There are many issues in that menu alone. I gave up even trying to get further into the site since there are no headings on the initial page and there are no landmarks. I am not filing bugs for all those. This design system needs a proper accessibility audit.

Edited to add specific items per https://github.com/carbon-design-system/carbon-components/issues/4#issuecomment-290780304

1. The navigation menu is not in a <nav> element (which can be used to hook state information via ARIA as well as act as a landmark navigation point — see item 7).
2. <button class="side-nav__toggle-btn"> (the button to collapse the menu) has no accessible name; it is announced as “button”.
3. When activated, the state of the menu is not conveyed (aria-expanded might be a fit) regardless of whether it is collapsed or not.
4. When collapsed, the menu is still in tab order. The style hiding it is transform: translateX(-100%);. display:none; would hide it from AT and keyboard use (though the toggle button would have to move out of that container).
5. Sub-menus are never removed from focus order, whether the parent navigation item is collapsed or the entire menu is. This is because they are only hidden via an inline max-height: 0px;. I understand that animation effects are desired here, but those can still be achieved accessibly.
6. There are no headings on the page, so a screen reader user cannot just jump into the page content. For example, you could replace all the <div>s around individual letters of the branding with an <h1> and still retain your visual design, perhaps using ARIA so it gets announced as words instead of letters. As another example, <p class="overview-page__tile--heading">Carbon design kit</p> should be <h2 class="overview-page__tile--heading">Carbon design kit</h2>
7. There are no landmarks on the page, so a screen reader user cannot just jump into the page content nor other parts. For example, <section class="overview-page"> should probably be <main class="overview-page">. <div class="side-nav__footer"> should probably be <footer class="side-nav__footer">. <div class="side-nav"> as <nav class="side-nav"> (excluding the footer).

[marijohannessen]

@aardrian I just merged in a PR that should address all the items on your list. I won’t be able to add any more fixes until Monday, but you should at least be able to get past the side navigation now.

Next week, we are going to do a full accessibility audit on the site, so if you have any helpful resources regarding SPAs and accessibility then I would love to check them out.

[aardrian]

Holy cow that is so much better. I can actually jump to the main landmark, or back to the nav, or navigate by heading. Even if you had not fixed the navigation display I could still finally get around.

I think you know there are some tweaks needed, but this is a great first step for me to be able to even get in to evaluate the design patterns.

Thank you for addressing this so quickly.

Quick FYI on the navigation toggle button, it does not need tabindex="0" as it is already in the default tab order just by being a native interactive control. The <a tabindex="0" class="skip-to-content">Skip to main content</a> should not need it either if you use href="#maincontent" . Since you have a tabindex="0" on the <main> element that will allow it to accept focus from the link for all those broken WebKit browsers.

As for SPAs and accessibility, that is a tough request. Each SPA framework does things its own way, so while there are libraries that can help (like ngAria for Angular) that does not guarantee accessibility. I have not used React, but I am aware somebody made a tool to test React applications for accessibility (though it has not been updated in a while). You may also want to look at Tenon, which can be integrated into your development workflow to catch issues as you go instead of them being treated as bug reports later.

As long as those SPAs output valid HTML that makes interactive controls out of real interactive elements then you are already in good shape (ie, you should never put an onclick on a <div> without a heck of a good reason). Good page structure, valid semantic and structural HTML tends to bring accessibility along for free.