aria-practices
aria-practices copied to clipboard
w3c
Do the ARIA TABS 1.2 fail WCAG 1.4.10 Reflow?
When using the zoom instructions from the Understanding Success Criterion 1.4.10: Reflow setting a screen width of 1280px @400% browser zoom the Tabpanel content is truncated and horizontal scrolling occurs.
My personal testing demonstrates that the Tabs do reflow or stack, however the Tabpanel content does not reflow.
ALT=ARIA Tabs example zoomed and content is cut off.
ALT=Showing Chrome Developer tools where I have removed all other page content so that only the Tab widget is available.
I think that's a border case. The element itself is exactly 320 px wide (tablist+tabpanel), but with the padding from the body it happens that not the tabpanel has to be scrolled, but the whole page to get the tabpanel completely in the visible area.
At VMware, we tackled this with an overflow Tabs design as seen in the "Overflow Tabs" example http://www.chrislane.info/clarity3demo1/. The tradeoff in this implementation, is that there is a button that only sighted mouse users need.
Per conversation in August 2, 2022 Telecon:
- Since this example is intended to be the simplest possible implementation, reduce to 3 tabs and change minwidth from 550 to approximately 320 (potentially less depending on padding.
- This will make the current examples WCAG compliant.
-
- We need a more advanced tabs example that illustrates how to be WCAG compliant with more tabs. This could include a menu for choosing which tabs are displayed or chevrons that intelligently scroll the tablist.
Per conversation in August 2, 2022 Telecon:
- Since this example is intended to be the simplest possible implementation, reduce to 3 tabs and change minwidth from 550 to approximately 320 (potentially less depending on padding.
- This will make the current examples WCAG compliant.
- We need a more advanced tabs example that illustrates how to be WCAG compliant with more tabs. This could include a menu for choosing which tabs are displayed or chevrons that intelligently scroll the tablist.
In taking a closer look at this, it looks like there will still be two scroll bars if we reduce to 3 tabs and lower the minwidth. We would need to reduce to probably 2 tabs to prevent wrapping of the tabs and prevent a scroll bar at the bottom of the browser. The intent of the standard is that there should be either a horizontal or vertical scroll bar at the browser page level, not both. One or the other and they definitely prefer vertical scrolling.
The intent of this Success Criterion is to support people with low vision who need to enlarge text and read it in a single column. When the browser zoom is used to scale content to 400%, it reflows - i.e., it is presented in one column so that scrolling in more than one direction is not necessary.
There are also exceptions built in to this standard where the visual layout of the content is essential for the user to understand it's meaning. Data tables are a prime example where reflowing the data table content would make it unusable visually. This tabs example is the same sort of case in that wrapping the tabs causes the tab list to essentially lose it's meaning - the tabs no longer appear associated to one another or to their owned content.
Content which requires two-dimensional layout for usage or meaning cannot reflow without losing meaning, and is therefore out of scope of this Success Criterion. For example, graphics and video are by their nature two-dimensional. Cutting up an image and stacking the blocks would render the content unusable so that is out of scope. It is acceptable to provide two-dimensional scrolling for such parts of the content.
The allowance here is that we can provide two dimensional scrolling for the this content and not for the entire page. We can achieve this via CSS: overflow-x:auto; on the outer div.
Following is a screen shot of the proposal, showing a vertical scrollbar at the browser level and a horizontal scroll bar a the content level.
@curtbellew
It is important that the content of the tabpanel does not have to be scrolled horizontally to read it!
If the tablist needs to be scrolled horizontally, I don't think it's that problematic, but I don't know if that meets any of the 1.4.10 exceptions. For the tablist not to have to be scrolled horizontally, there are 3 possibilities:
- Reflow
- Show a button at the end of the visible tablist to display more tabs (via dropdown)
- Show a button on the right and left side of the visible tablist to show more tabs (a kind of scroll function without scrollbar)
@curtbellew
It is important that the content of the tabpanel does not have to be scrolled horizontally to read it!
If the tablist needs to be scrolled horizontally, I don't think it's that problematic, but I don't know if that meets any of the 1.4.10 exceptions. For the tablist not to have to be scrolled horizontally, there are 3 possibilities:
- Reflow
- Show a button at the end of the visible tablist to display more tabs (via dropdown)
- Show a button on the right and left side of the visible tablist to show more tabs (a kind of scroll function without scrollbar)
These are some methods of addressing the issue but the point of this standard remains the 2 dimensional scrolling. As with any standard there are many ways to address it. In this particular case the most straightforward way to fix this issue is via the horizontal content scrolling as outlined in the standard. That solution is outline within the standard, please feel free to review the standard.
The current implementation of tabpanels is clearly a violation of SC 1.4.10 because they must be scrolled horizontally after each line of text.
The display has thus worsened significantly compared to the initial findings.
The ARIA Authoring Practices (APG) Task Force just discussed ARIA TAB pattern and WCAG 1.4.10 Reflow.
The full IRC log of that discussion
<jugglinmike> Topic: ARIA TAB pattern and WCAG 1.4.10 Reflow<jugglinmike> github: https://github.com/w3c/aria-practices/issues/2284
<jugglinmike> CurtBellew: the short-term suggestion is to remove one or two of the tabs so that the content fits inside the frame and doesn't produce the scrollbars
<jugglinmike> CurtBellew: I found that scrollbars remained even after removing one of the tabs
<jugglinmike> CurtBellew: The solution might work, but we'll have to remove more than one tab
<jugglinmike> CurtBellew: As an alternative, we can produce verticle scrollbar, but one present only for the content which requires it (rather than for the entire document)
<jugglinmike> Matt_King: I'm wondering if tabs are the right user-interface design for this situation
<jugglinmike> Matt_King: We may need two examples. One for the "super-simple" case with a small number of tabs, and another that's more complicated and supports any number of tabs
<jugglinmike> jongund: We could use "overflow: hidden" with elipses so that as the text squeezes, you'll see just the beginning of each tab
<jugglinmike> JamesNurthen: I think a "simple" example like what Matt_King has proposed would help us write tests, but I don't think it's realistic for people to use that in the real world. Overflow occurs so commonly that an example which doesn't support it isn't very useful
<jugglinmike> Matt_King: Maybe the "simple" example should demonstrate the use of icons as table labels, since that is a more realistic application of a tab list which doesn't necessarily overflow
<jugglinmike> Jem: Chris Lane has a demo for "Overflow Tabs" which incorporates a drop-down to include tabs which would otherwise cause overflow
<jugglinmike> Jem: http://www.chrislane.info/clarity3demo1/
<jugglinmike> JamesNurthen: I couldn't get this "menu button in a tab list" ready in time for APG version 1.3
<jugglinmike> Summary: We need proposals for icon tabs, and we need to open a separate issue for how we're going to handle overflow
