WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility of responsive, repositioned sidebars?

for

From: Jonathan Avila
Date: Oct 31, 2016 11:34AM

> If I tab past the last menu item in the main horizontal navigation at the top of the page, I, personally, would expect the next tab stop to be the first link in the main content area (left column), not the first link in the secondary navigation menu (right column). This would be the case whether that secondary navigation was made to appear there using float:right with CSS or by using the order property in the flexbox model.

From what I understand if the order property is used in Firefox the tab order will actually change to match the visual order and not the source order.

> Jonathan, I'm interpreting what you've said as falling on the "It's probably not that big a deal either way" side of things in the scenario described above. That sound right?

Right, as long as the sequence is still meaningful there would appear to be allowances for some deviation from the visual order.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
<EMAIL REMOVED>
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Robert Fentress
Sent: Monday, October 31, 2016 1:27 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessibility of responsive, repositioned sidebars?

Thanks.

I certainly *can* change the visual order using flexbox or CSS, but my question is if I *should*, when that means the tab order no longer matches the visual order.

For instance, assume the following for a desktop view: There is a row containing a full-width banner at the top of the page followed by a row containing a horizontal main navigation bar that stretches across the full width of the page, followed by a row with two columns, where the left column is the main page content, including some links embedded in a paragraph, and the right column is a vertical secondary nav.

If I tab past the last menu item in the main horizontal navigation at the top of the page, I, personally, would expect the next tab stop to be the first link in the main content area (left column), not the first link in the secondary navigation menu (right column). This would be the case whether that secondary navigation was made to appear there using float:right with CSS or by using the order property in the flexbox model.
If this is, indeed, problematic, is it better, then, to use Javascript to rearrange the DOM, so that the tab order always matches the visible order?
Though this seems less elegant, if one used matchMedia, it would be less so.

Jonathan, I'm interpreting what you've said as falling on the "It's probably not that big a deal either way" side of things in the scenario described above. That sound right?

Adding a further wrinkle, sometimes there are layouts where a secondary navigation menu and other supplementary content both appear together in a right-side column on large viewports, but, on small viewports, the secondary menu breaks above the main content, while the other supplementary content breaks below. Ugh!

On Wed, Oct 26, 2016 at 11:54 AM, Asa Baylus < <EMAIL REMOVED> > wrote:

> Hi Robert,
>
> I just went through this same issue. It's trivial to solve if you're
> using flexbox. With flexbox you can change the order without JS
>
> Browser support is pretty decent these days
>
> Just a thought and your browser support matrix may not allow for it
>
> Asa
>
> Sent from my iPhone
>
> > On Oct 26, 2016, at 8:45 AM, Robert Fentress < <EMAIL REMOVED> > wrote:
> >
> > Bummer. Nobody has an opinion, or was I just not clear in my
> > explanation of the issue?
> >
> >> On Tue, Oct 18, 2016 at 10:21 AM, Robert Fentress < <EMAIL REMOVED> > wrote:
> >>
> >> Hello, all.
> >>
> >> Anybody got opinions on the accessibility of responsive designs
> >> where a secondary menu appears as a column to the right of the main
> >> content on desktop breakpoints, but, on mobile, the menu appears
> >> above the main content, perhaps in a disclosure widget of some
> >> sort? In both cases,
> the
> >> DOM order has the menu before the main content, with the visual
> >> changes being accomplished using CSS.
> >>
> >> From a design perspective, the fact that the main content dominates
> >> visually on desktop is probably good and making the menu easier to
> >> get
> to
> >> by preceding the content on mobile makes sense (though it gets
> complicated
> >> when you consider ease of access and hand position). My question,
> though
> >> is how bad it is that the DOM order now does not match the tab
> >> order for keyboarders? Certainly, this is not an uncommon pattern
> >> on the web
> these
> >> days. Perhaps, it would not terribly violate user expectations.
> >>
> >> Beyond the tab order, simply having the visual order not match the
> >> DOM order appears to be a no-no for various reasons, based on "C27:
> >> Making the DOM order match the visual order"
> >> <https://www.w3.org/TR/WCAG20-TECHS/C27.html>. However, this is
> >> but
> one
> >> sufficient condition for meeting the related success criterion,
> >> 1.3.2 Meaningful Sequence
> >> <https://www.w3.org/WAI/WCAG20/quickref/#qr-content-
> structure-separation-sequence>.
> >> C27 says:
> >>
> >> "If this is a sufficient technique for a success criterion, failing
> >> this test procedure does not necessarily mean that the success
> >> criterion has
> not
> >> been satisfied in some other way, only that this technique has not
> >> been successfully implemented and can not be used to claim conformance."
> >>
> >>
> >> So, it seems ambiguous to me.
> >>
> >> Would it be better to actually move the content with JavaScript at
> smaller
> >> breakpoints so the DOM order matches the visual order? That
> >> strikes me
> as
> >> inelegant (though less so as matchMedia
> >> <http://caniuse.com/#feat=matchmedia>; gains ground) and more likely
> >> to break. It may also confuse users who move between devices.
> >>
> >> What do you folks think about the relative advantages and
> >> disadvantages
> of
> >> various approaches?
> >>
> >> Thanks.
> >>
> >> Best,
> >> Rob
> >>
> > > > > > archives at http://webaim.org/discussion/archives
> > >
> > > archives at http://webaim.org/discussion/archives
> >