WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: QuestionVisual button order versusannouncedbutton focus order

for

From: Moore,Michael (HHSC)
Date: Jul 10, 2015 9:48AM

The screen reader will normally read in source code order. The exception is when you have used a positive tab index and the user is moving through the form using the tab key to navigate active element to active element. In this case it will follow the specified tab sequence. Positive tab indexes are considered harmful in most cases. If you think that you need them there is probably something wrong with your source code order.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Chamberland, Robert
Sent: Friday, July 10, 2015 10:22 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Question re: Visual button order versus announced button focus order


I think from a usability perspective having focus go to Submit first may satisfy the requirement to be meaningful.

I'm still mulling over the suggestion to left align or stack the series of <buttons>.

What comes to mind:

1) I would just point out these kinds of buttons are very common and usually associated with payment processing forms, often with arrows, and after filling out payment info users expect that the next logical step is to move forward in linear fashion to the next page in the sequence, hence placing focus on the rightmost "submit" or "next".

2) I'm not getting a sense from the comments so far that there's any contravention of standards or best practices in this instance of visual order being different from the announced or focus order.

3) If the language chosen is right to left, now "forward" is to the left, "back" is to the right. The stylesheet will flip the layout around. So this brings up a whole other question (probably should be its own topic):

Does anyone know if screen readers will be reading from HTML source code, and so will read the buttons in the order they're coded (top to bottom, left to right), or as CSS has styled the buttons (e.g. left or right aligned, then announced from left to right or right to left as defined by dir and lang)?

Thanks all for your input!

Rob C

-----Original Message-----
From: Cliff Tyllick [mailto: <EMAIL REMOVED> ]
Sent: Wednesday, July 08, 2015 6:34 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Question re: Visual button order versus announced button focus order

Tim, I agree that the visual order should match the tab order, but I would still insist on "Submit" being first, followed by "Back" and, if necessary, "Cancel." (I suspect that's what you meant, but you didn't actually say that was the order that should be matched.)

That's not just the way I understand WCAG's guidance for "Meaningful sequence." It's also what has worked best every time I've done usability testing on an electronic form or Web application.

I agree with Mike Moore that left-aligning the buttons, either in a single row or stacked in a column, is the best way to go.

Whenever I see a design that leads me in another direction, first I ask myself whether we've produced the best design, and then I suggest that we do a lot of usability testing to make sure that the design is as usable as it needs to be.

It could be that the answers are "Yes, it's a good design," and "Yes, it's highly usable and error-free."

It could be. But it would be very unusual. ;-)

Cliff Tyllick
Accessibility Specialist
Texas Department of Assistive and Rehabilitative Services

Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Jul 8, 2015, at 2:53 PM, Tim Harshbarger < <EMAIL REMOVED> > wrote:
>
> Why is the visual order different from the focus/reading sequence order?
>
> Unless there is some major benefit to making it look one way and work another way, I would just make the reading and focus order match the visual order. There really doesn't seem to be any major accessibility problem with how the visual order is presented. Make it look and work the same and there shouldn't be any concern about the focus and reading order.
>
> Thanks!
> Tim
>
>
>
>
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Chamberland, Robert
> Sent: Wednesday, July 08, 2015 10:03 AM
> To: <EMAIL REMOVED>
> Subject: [WebAIM] Question re: Visual button order versus announced
> button focus order
>
>
> Hi All,
>
> We have a situation where a form page has the buttons coded as:
>
> <button> Submit </button>
> <button> Back</button>
> <button> Cancel</button>
>
> And we'd use CSS to float the submit button to the right and position the back button on the left, so visually it is displayed as Back, Cancel and Submit. The Back button is visually on the left, where a left arrow might be. The Submit button is visually on the right, where a right arrow might be. The Cancel button will be in between.
>
> The thinking is that the Submit button, the one on the right, should by design receive focus first after coming out of the form inputs. Then, if tabbing, the Back button should receive the next focus, followed by Cancel.
>
> But obviously, the visual order as displayed is not the same as the focus order announced by the screen reader (I'm assuming the screen reader will always announce according to focus order, which could be wrong). The visual user sees Cancel, Back, Submit, in that order, reading or scanning from left to right. The screen reader presumably announces Submit, tabbing to Back and then Cancel, in that order.
>
> SC 1.3.2 (Meaningful Sequence) and SC 2.4.3 (Focus Order) don't quite seem to "fit" this question except to say that "Focusable components need to receive focus in an order that preserves meaning and operability only when navigation sequences affect meaning and operability." Is this such a case?
>
> It does seem to go against the spirit of C27: Making the DOM order match the visual order<http://www.w3.org/TR/WCAG20-TECHS/C27.html>; and also of G59: Placing the interactive elements in an order that follows sequences and relationships within the content<http://www.w3.org/TR/WCAG20-TECHS/G59.html>;, but these are techniques.
>
> In not following the visual order is this a faux pas? Is some meaning lost in showing the visual user one order, the screen reader user something else?
>
> Any feedback would be appreciated and thank you.
>
> Rob Chamberland
>
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
>