E-mail List Archives

Re: Accessibility of responsive, repositioned sidebars?

for

From: Robert Fentress
Date: Oct 31, 2016 1:14PM


Thanks for following up, Jonathan.

I hadn't thought to check with Firefox. I just did and see, that it does,
indeed, work as you describe there. I had only checked with Chrome, where,
unfortunately, flexbox-assigned order doesn't appear to have any effect on
tab order. So, it looks like that still won't solve the problem (?),
unless I am overlooking something. How depressing!

On Mon, Oct 31, 2016 at 1:34 PM, Jonathan Avila < <EMAIL REMOVED> >
wrote:

> > 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
> > > >
> > > at http://webaim.org/discussion/archives
> > > > > >



--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061