E-mail List Archives
Thread: QuestionVisual button order versus announced button focus order
Number of posts in this thread: 10 (In chronological order)
From: Chamberland, Robert
Date: Wed, Jul 08 2015 9:02AM
Subject: QuestionVisual button order versus announced button focus order
No previous message | Next message →
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
From: Moore,Michael (HHSC)
Date: Wed, Jul 08 2015 10:18AM
Subject: Re: QuestionVisual button order versus announced buttonfocus order
← Previous message | Next message →
If the submit is on the right side of the page and back and cancel are on the left then people using screen magnifiers or even browser magnification may have a problem finding the submit button.
Consider changing the design.
Place the three buttons on the left hand side of the page either sequentially in a row with submit first or stacked with submit being on the top.
Tab order should definitely start with submit since that is the action that you probably want people to make.
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 ADDRESS REMOVED = ] On Behalf Of Chamberland, Robert
Sent: Wednesday, July 08, 2015 10:03 AM
To: = EMAIL ADDRESS 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
From: _mallory
Date: Wed, Jul 08 2015 12:16PM
Subject: Re: QuestionVisual button order versus announced buttonfocus order
← Previous message | Next message →
On Wed, Jul 08, 2015 at 04:18:51PM +0000, Moore,Michael (HHSC) wrote:
> If the submit is on the right side of the page and back and cancel are on the left then people using screen magnifiers or even browser magnification may have a problem finding the submit button.
Depends on how wide this page is-- most of our forms, the submit
being on the right is closest to the end of the last input, whereas
left is usually quite far away... so I'd say the design strongly
influences this.
_mallory
From: Tim Harshbarger
Date: Wed, Jul 08 2015 1:53PM
Subject: Re: QuestionVisual button order versus announced buttonfocus order
← Previous message | Next message →
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 ADDRESS REMOVED = ] On Behalf Of Chamberland, Robert
Sent: Wednesday, July 08, 2015 10:03 AM
To: = EMAIL ADDRESS 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
From: Cliff Tyllick
Date: Wed, Jul 08 2015 4:33PM
Subject: Re: QuestionVisual button order versus announced button focus order
← Previous message | Next message →
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 ADDRESS 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 ADDRESS REMOVED = ] On Behalf Of Chamberland, Robert
> Sent: Wednesday, July 08, 2015 10:03 AM
> To: = EMAIL ADDRESS 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
>
> > > > > > > >
From: Tim Harshbarger
Date: Wed, Jul 08 2015 6:49PM
Subject: Re: QuestionVisual button order versus announcedbutton focus order
← Previous message | Next message →
Actually, Cliff, you were kindly attributing more insight to my answer than I had.
I was reluctant to suggest an order for the buttons because I didn't really have any data to support one approach over another. I could think of some reasons why one order might be better than another but they were all based on me making assumptions about users I would be uncomfortable with unless I had some real usability data to base those assumptions on. Fortunately, it sounds like you have that insight.
Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Cliff Tyllick
Sent: Wednesday, July 08, 2015 5: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 ADDRESS 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 ADDRESS REMOVED = ] On Behalf Of Chamberland, Robert
> Sent: Wednesday, July 08, 2015 10:03 AM
> To: = EMAIL ADDRESS 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
>
> > > > > > > >
From: Eades, Terri
Date: Thu, Jul 09 2015 9:07AM
Subject: Re: QuestionVisual button order versus announcedbutton focus order
← Previous message | Next message →
I disagree with left-aligning if your form is wide. The reason why having them right-aligned works is because people read from left to right so if I get to the end of the form and the submit button isn't right there, I have to look for it, especially if I have to distinguish it from other buttons. Now, since you have three buttons, center-aligning might be a compromise and order them Submit | Back | Cancel. Also, put your desired action, (Submit), in a different color so that your sighted users will be more likely to click that instead of accidently hitting Back or Cancel. This way, the buttons are still in the correct order for screen reading software, but there is still something distinguishing the action you want visitors to take. (Which is why I'm guessing you have the original layout with the Submit button separate from the others.) Just remember to pick your colors wisely for colorblind users and make sure there is significant contrast between the Submit button and the others (ie dark vs. light).
Terri Eades
Webmaster
Morgan Community College
920 Barlow Road, Fort Morgan, CO 80701
Phone: (970) 542-3155 | Fax: (970) 542-3115
= EMAIL ADDRESS REMOVED =
www.MorganCC.edu
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Cliff Tyllick
Sent: Wednesday, July 08, 2015 4: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 ADDRESS 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 ADDRESS REMOVED = ] On
> Behalf Of Chamberland, Robert
> Sent: Wednesday, July 08, 2015 10:03 AM
> To: = EMAIL ADDRESS 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
>
From: Chamberland, Robert
Date: Fri, Jul 10 2015 9:22AM
Subject: Re: QuestionVisual button order versus announcedbutton focus order
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ] On
> Behalf Of Chamberland, Robert
> Sent: Wednesday, July 08, 2015 10:03 AM
> To: = EMAIL ADDRESS 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
>
From: Moore,Michael (HHSC)
Date: Fri, Jul 10 2015 9:48AM
Subject: Re: QuestionVisual button order versusannouncedbutton focus order
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ] On
> Behalf Of Chamberland, Robert
> Sent: Wednesday, July 08, 2015 10:03 AM
> To: = EMAIL ADDRESS 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
>
From: Graham Armfield
Date: Fri, Jul 10 2015 10:54AM
Subject: Re: QuestionVisual button order versus announced button focus order
← Previous message | No next message
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ] On
> > Behalf Of Chamberland, Robert
> > Sent: Wednesday, July 08, 2015 10:03 AM
> > To: = EMAIL ADDRESS 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
> > > > > >