WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Accessibility of responsive, repositioned sidebars?

for

Number of posts in this thread: 10 (In chronological order)

From: Robert Fentress
Date: Tue, Oct 18 2016 8:21AM
Subject: Accessibility of responsive, repositioned sidebars?
No previous message | Next message →

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

From: Robert Fentress
Date: Wed, Oct 26 2016 6:45AM
Subject: Re: Accessibility of responsive, repositioned sidebars?
← Previous message | Next message →

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 ADDRESS 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
>

From: Jonathan Avila
Date: Wed, Oct 26 2016 6:54AM
Subject: Re: Accessibility of responsive, repositioned sidebars?
← Previous message | Next message →

> Bummer. Nobody has an opinion, or was I just not clear in my explanation of the issue?

CSS Flexible box has the ability to allow programmatic ordering that does not match the DOM order. There is some disagreement on whether it should or not. But this would likely help you solve the issue if people can agree. Browsers implement it differently now.

https://www.w3.org/TR/css-flexbox-1/

Right now since the DOM order is it -- you would have to change the DOM itself to control the order in some situations like you discuss. I'd think that people have been flexible in interpreting 1.3.2 meaningful sequence to allow for the visual order to be different as long as it is still meaningful.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS 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 ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Wednesday, October 26, 2016 8:45 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessibility of responsive, repositioned sidebars?

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 ADDRESS 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
>

From: Lovely, Brian (CONT)
Date: Wed, Oct 26 2016 7:18AM
Subject: Re: Accessibility of responsive, repositioned sidebars?
← Previous message | Next message →

Going from side by side on desktop to one above the other on mobile is an improvement over pinch zooming a miniature of the desktop version. If the top to bottom order of the mobile version matches the top to bottom, left to right order of the desktop I don't think there's any problem.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Wednesday, October 26, 2016 8:45 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility of responsive, repositioned sidebars?

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 ADDRESS 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
>
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

From: Asa Baylus
Date: Wed, Oct 26 2016 9:54AM
Subject: Re: Accessibility of responsive, repositioned sidebars?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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
>>
> > > >

From: Robert Fentress
Date: Mon, Oct 31 2016 11:26AM
Subject: Re: Accessibility of responsive, repositioned sidebars?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> >>
> > > > > > > > >
> > > > >

From: Jonathan Avila
Date: Mon, Oct 31 2016 11:34AM
Subject: Re: Accessibility of responsive, repositioned sidebars?
← Previous message | Next message →

> 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> >

From: Robert Fentress
Date: Mon, Oct 31 2016 1:14PM
Subject: Re: Accessibility of responsive, repositioned sidebars?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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

From: Robert Fentress
Date: Tue, Nov 01 2016 6:54AM
Subject: Re: Accessibility of responsive, repositioned sidebars?
← Previous message | Next message →

Here is some further info from discussions at the W3C:
https://lists.w3.org/Archives/Public/www-style/2014Nov/0345.html

Looks like the consensus was that flexbox order should be purely visual and
should not affect the logical order for the purposes of tab or virtual
cursor navigation.

On Mon, Oct 31, 2016 at 3:14 PM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:

> 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
>



--
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

From: Jonathan Avila
Date: Tue, Nov 01 2016 8:43PM
Subject: Re: Accessibility of responsive, repositioned sidebars?
← Previous message | No next message

> Looks like the consensus was that flexbox order should be purely visual and should not affect the logical order for the purposes of tab or virtual cursor navigation.

That was in 2014. I think there is some new discussion around the topic that may change the original thinking. But as you imagine it's not something that will immediately make it into browsers as there is some complexity to the subject. There is disagreement as to whether the Firefox behavior is a bug or works as designed.

Jonathan

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Tuesday, November 01, 2016 8:54 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessibility of responsive, repositioned sidebars?

Here is some further info from discussions at the W3C:
https://lists.w3.org/Archives/Public/www-style/2014Nov/0345.html

Looks like the consensus was that flexbox order should be purely visual and should not affect the logical order for the purposes of tab or virtual cursor navigation.

On Mon, Oct 31, 2016 at 3:14 PM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:

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



--
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