WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: QuestionVisual button order versus announced button focus order

for

From: Graham Armfield
Date: Jul 10, 2015 10:54AM

It's surely important to have the Submit button first in the content order
- if that's the usual response required from the form.

Don't forget that the first button in any form becomes the default button.
So if a user presses Enter whilst in the form the default button action is
the one that gets fired - unless of course you have somehow overridden that.



Regards
Graham Armfield



coolfields.co.uk <http://www.coolfields.co.uk/>;
M:07905 590026
T: 01483 856613
@coolfields <https://twitter.com/coolfields>

On Fri, Jul 10, 2015 at 4:48 PM, Moore,Michael (HHSC) <
<EMAIL REMOVED> > wrote:

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