Contrib.social

Accessibility bugs with vertical tabs

Open on Drupal.org →
Created on 16 September 2019, over 5 years ago
Updated 7 April 2023, over 1 year ago

Problem/Motivation

Vertical tabs have the many accessibility issues. At the most basic level, tablist/tab/tabpanel aria roles are not in use. More specific issues are described below.

To see these issues on a plain Drupal 9 site, install Drupal with the standard or Umami install profile, and check a text format settings form (i.e. /admin/config/content/formats/manage/filtered_html), or a block layout config form (i.e. /admin/structure/block/manage/claro_page_title).

  1. Drupal.verticalTab aria-expanded="false" aria-pressed="false". This is expected behavior. When content is displayed as vertical tabs, there are hidden details/summary elements. The pressed/expanded will not change as they are hidden. On narrow viewports these details/summary elements are visible (it must be a narrow viewport when the page loads for them to appear), and the aria attributes update properly.
  2. Drupal.verticalTab marks active vertical tab menu items with an element that text is active tab. The element has a non-unique CSS id #active-vertical-tab. Sadly, this will be very wrong on the filter format and editor configuration form where multiple vertical tabs may appear (e.g. /admin/config/content/formats/manage/basic_html).

    Fearing the duplicated id, if the user changes the active tab, this marker will be removed from every other vertical tab's of the page as well

    • May 9, 2022, alisonjo315: I don't see this issue on a plain Drupal 9 site, probably it's been fixed since September 2019? -- but, I'll leave it here for now, until a second person confirms what I'm seeing.
    • Mar 29, 2023, bnjmnm: this is still happening. Currently the contents of #active-vertical-tab are how the active tab is conveyed to AT. If there are multiple sets of vertical tabs on a page, only one of those sets can have #active-vertical-tab at a given time. For example, on a text format page, select a tab in plugin settings, and note that #active-vertical-tab is added to that tab. Then choose a tab in filter settings (a different set of vertical tabs). Those tabs now have #active-vertical-tab to indicate the just-pressed tab, but that same indicator is no longer present in the plugin settings tabs.

      This is because any time a vertical tab is pressed this code runs: $('#active-vertical-tab').remove();, which removes all "active tab" elements, when the intent is to only remove it within the vertical tabs group where the new tab was pressed.

  3. Auto-focus bug: When a vertical tab is activated (triggered to be shown) by pressing Enter on the tab menu link Drupal.verticalTab tries to focus the first visible :input element in a vertical tab content. But the implementation is wrong. The effects are most obvious on pages with multiple vertical tab groups.

    For example, on the Filter format and editor form (/admin/config/content/formats/manage/basic_html), if you press the Enter key to select a tab under Filter settings (the last vertical tabs element on the page), the focus should be on the tab you just selected, but instead, the focus is moved to the first vertical tabs further up on the page (CKEditor plugin settings).

    This is because the focus trigger happens globally; it isn't limited to the current vertical tabs.
  4. The label of a vertical tabs element has invalid for attribute value.

    From #3023310-85: Vertical Tabs style update → .2:

    (...) the for attribute is looking for an ID that is not present on the page. The value it is looking for does appear in a div's data-drupal-selector attribute, an element that can't receive focus.

Added May 9, 2022:

  1. Should be able to press enter or spacebar to activate a vertical tab.
  2. Attribute aria-selected is missing from tab elements -- it should be present and have a value of true/false based on whether the tab is active.
  3. Each tab should have attribute aria-controls, pointing to the related tabpanel ID.
  4. Attribute tabindex="-1" must be present on all non-active tabs (and tabindex="0" on active tabs).
  5. When I tab through the form, it should take me into the "active" tabpanel and then out of the tablist -- right now, it takes me through the tablist, then into the tabpanel. (If I press spacebar/enter on a tab, it does move focus to the active tabpanel then out of the tablist; it should behave like this with tabs that are open by default/on page load, too.)
  6. Using up/down arrow keys while focused on a tab should take user to the next or previous tab.

Proposed resolution

Many of the above issues can be addressed by converting the tabs to use the recommended pattern from MDN/W3C
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tab_role

https://www.w3.org/WAI/ARIA/apg/example-index/tabs/tabs-automatic

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

@todo

🐛 Bug report
Status

Needs work

Version

10.1 ✨

Component
Javascript  →

Last updated 1 day ago

Created by

🇭🇺Hungary huzooka Hungary 🇭🇺🇪🇺

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • JavaScript

    Affects the content, performance, or handling of Javascript.

  • Needs accessibility review

    Used to alert the accessibility topic maintainer(s) that an issue significantly affects (or has the potential to affect) the accessibility of Drupal, and their signoff is needed (see the governance policy draft for more information). Useful links: Drupal's accessibility standards, the Drupal Core accessibility gate.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇺🇸United States bnjmnm Ann Arbor, MI

    It's worth noting that comment #63 is not pointing out anything wrong with the changes being made in this issue. It's an unrelated pre-existing issue that was not caused by any of the accessibility fixes here and has its own issue. Patch #61 is still ready for review.

  • Comment almost 2 years ago →
    🇷🇺Russia Chi

    @bnjmnm, That's correct, but patch #61 made the problem outlined in 🐛 Claro: Wrong background for active vertical tab Fixed much more noticeable. I propose we postpone this issue till 🐛 Claro: Wrong background for active vertical tab Fixed is resolved.

  • Comment almost 2 years ago →
    🇮🇳India gauravvvv Delhi, India
  • Status changed to Needs work almost 2 years ago
  • Comment almost 2 years ago →
    🇺🇸United States smustgrave

    Testing patch #61 on /admin/structure/block/manage/claro_page_title
    Notice the aria-expanded and aria-pressed still remain false.

  • Status changed to Needs review over 1 year ago
  • Comment over 1 year ago →
    🇺🇸United States bnjmnm Ann Arbor, MI

    #69 is expected behavior. When vertical tabs are visible, the details and summary elements are hidden and inert and the attributes should not change. I updated the issue summary to clarify this.

    Also, 🐛 Claro: Wrong background for active vertical tab Fixed is complete.

  • Status changed to RTBC over 1 year ago
  • Comment over 1 year ago →
    🇺🇸United States smustgrave

    For accessibility rule

    Tested on /admin/structure/block by adding a block
    I can tab to vertical tabs and using my up/down arrows cycle through them.
    Pressing enter opens the tab and moves focus to the first focusable element.
    aria-selected attribute correctly updates.
    The "a" tag for each tab aria-controls correctly points to the aria-own attributes with matching values.
    The "a" tag that is active currently has tabindex="0" while the rest are -1

    Also tested on /admin/config/content/formats/manage/full_html where 2 tab groups exists and had no issues of focus going to the wrong group,

    Going to mark this and ask #accessibility channel if my review was good enough.

    @bnjmnm you tagged for follow up 2 years ago that still needed?

  • Status changed to Needs work over 1 year ago
  • Comment over 1 year ago →
    🇺🇸United States benjifisher Boston area

    We discussed this issue briefly at 📌 Drupal Usability Meeting 2023-04-07 Fixed . That issue will have a link to a recording of the meeting.

    For the record, the attendees at today's usability meeting were @benjifisher, @mgifford, @rkoller, @simohell, and @swirt.

    We were not sure exactly what was supposed to change, since we did not follow the links in the "Proposed resolution" section of the issue summary. But we did notice one problem with vertical tabs in the block configuration page (same as the screenshot from Issue #63).

    1. Use the mouse to select the Pages vertical tab.
    2. Tab to select Roles.
    3. Enter to select the vertical tab. Focus shifts to the checkboxes in that tab.
    4. Shift-tab. The focus goes to the last vertical tab (Vocabulary).

    In Step 4, we expected the focus to return to Roles, not Vocabulary. We saw the same behavior with or without the patch from Comment #61.

    I am setting the issue status to NW to consider this behavior. If the actual behavior is what we want, or if it is out of scope for this issue, then feel free to change the status back to RTBC.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024