Are DesignPLUS Tabs accessible for students?

DesignPLUS Tabs are accessible because they are built to meet the WAI-ARIA pattern guidelines.

The first thing that is important to understand is that some DesignPLUS content transforms on the saved view of the page.  This means it looks different and has a different HTML structure in the editor compared to the saved view that students see.  For more information about this, see Why do some DesignPLUS elements look different in the editor compared to how they appear after saving?

DesignPLUS Tabs: Editor vs Saved View

Tabs are one of the three panel widget options offered by DesignPLUS.  The other two are Accordions and Expanders.  All three of these panel widget options look the same in the Canvas editor: a widget wrapper with panel groups consisting of a panel heading and content area. 

When Accordions and Expanders are transformed in saved view, the panel headings are transformed into triggers (but they are still headings) that expand/collapse the content and the heading-content structure is maintained.  However, when Tabs are transformed in saved view, the panel headings are transformed into an unordered list of tab buttons which are no longer headings.  This list of tab buttons is moved to the top of the widget wrapper, meaning the heading-content structure is not maintained.  This is how accessible tabs are designed; they are not meant to be a heading-content structure but a different structure altogether that uses a list of buttons to toggle the visible content in a viewing area.

For tab panel widgets, we intentionally use HTML in the editor with a heading-content structure so that if the DesignPLUS JavaScript code that transforms panels ever doesn't load (browser issues, Canvas issues, ending licensing, etc) then the tab panels deprecate to a simple and logical heading-content structure on the page.  But remember, just because this is the HTML structure in the editor, it does not mean that is how the HTML will appear in the saved view after the JavaScript transforms it.

Headings inside Tabs

Here's where things can get tricky.  In the editor, if a user designs a tabs panel widget and sets the panel headings to h3, they may want to put an h4 heading at the top of a panel content area.  In the editor, this causes no issues for heading hierarchy.  But in the saved view, the h3 headings transform into tab buttons and are removed from the heading hierarchy, meaning that the h4 is now out of order.  For this reason, if you put a heading at the top of your tab panel content in the editor, make it the same heading level as the panel heading so that hierarchy is preserved on saved view.

The DesignPLUS JavaScript that transforms panel widgets will place the panel heading at the top of the panel content on saved view if the panel content does not already start with a heading.  This heading is set to screenreader-only so as not to interfere with visual design.  This prevents any hierarchy issues if lower heading levels are used further down in the panel content.

Why Do My Tabs Get Flagged by Accessibility Checkers?

It's important to note that some accessibility checkers will check the pre-transformed HTML of Canvas content and some will check the post-transformed HTML.  DesignPLUS Tabs are designed to meet accessibility regardless of which version is scanned (heading-content structure in editor/raw HTML, and transformed tablist buttons for saved view).

Accessibility checkers will flag heading hierarchy on the transformed tabs only if you design a tab panel widget in the editor with a heading at the top of the panel content whose heading level is lower than the panel heading's level (e.g. panel heading h3, heading at the top of the content h4). 

Our code ensures proper hierarchy if you put the lower level heading further down in the panel content.  We recommend using the free WAVE Evaluation Tool extension to see this in action.

Tabs and Screen Readers

How Do I Use Screen Readers and Keyboard Shortcuts to Navigate Tabs?

DesignPLUS Tabs follow the same guidelines as the WAI-ARIA pattern guidelines, and so they can be navigated using the basic Tab, Arrow, and Enter keys, as explained in the Tabs Pattern Keyboard Interaction from the WAI-ARIA Website.

Why Are Tabs and Headings Inside of Tabs Not Included in the Heading List?

Tab buttons are not headings.  They do not appear in the Heading lists of screen reader software because they are not headings.  They are interactive controls that toggle the visibility of tab panel content. 

Many screen readers are designed to intentionally skip over Tabs and the content inside of Tabs for page structure purposes. If you use the "H" key to skip through headings on the page, Tabs and headings inside of Tabs may be skipped by the screen reader. Since Tabs are transformed into buttons, we recommend using the keyboard shortcuts to navigate Tabs as if they were buttons.

In many cases, headings nested inside of a tab panel will not appear in the overall page heading list either, even if the tab is visible and active. This is not a bug, but an intentional design choice to maintain a logical document structure. The heading list reflects the overall page structure, not the content of every possible state.  However, as the screen reader reads the panel content, it will announce headings inside the panel properly (even those set to screenreader-only by DesignPLUS).

DesignPLUS does not create accessible content by building to any specific screenreader platform.  We design to WCAG and the WAI-ARIA pattern guidelines.