E-mail List Archives
Thread: Screen reader Forms Mode as Only Interaction Method?
Number of posts in this thread: 5 (In chronological order)
From: Tim Harshbarger
Date: Thu, Mar 02 2017 2:43PM
Subject: Screen reader Forms Mode as Only Interaction Method?
No previous message | Next message →
Here is another way to look at this.
If a form is designed in a way that allows a screen reader to remain in forms mode when they are filling it out, they actually can complete the form a lot faster. If they have to switch back and forth, that is going to slow them down. I cannot think of any reason that would lead me to believe that people using screen readers want to spend any more time completing form fields than any other user or some reason that would make them less likely to abandon forms that make them do extra work to complete.
So if you can design your forms to enable screen reader users to remain in forms mode, that is probably best.
If you can't do that, then try to create forms that minimize the need to switch back and forth in order to complete the form successfully.
Sure, there are extremes where this approach might not work, but it probably is a decent approach if used wisely.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, March 02, 2017 1:04 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Screenreader Forms Mode as Only Interaction Method?
I think it depends a lot on the user.
But generally speaking, screen reader users tend to jump between form
fields, (using tab, or "f" which is the shortcut for moving to next
form field" or "e" to move to next edit field.
If you make sure to include general instructions for the form at the
beginning of the form you have covered most of your basis and you
probably don't really need much text between the form field.
But any tooltip that gets triggered onFocus, is not available if
screen readers browse through forms in browse mode (which is one of
the reasons I most frequently use tab).
You also have to be very careful about content order if you rely on
browsed mode.
If you see a bunch of form fields and then an error message, you may
not be totally sure if the error message is for the field before or
after the message itself. Users expect after, because you expect to
navigate from label to form to tool tip to error message.
If you associate messages explicitly using aria-describedby, you don't
have to worry about that order, and the error message and tooltip can
be placed before or after the form field (or at the end of the DOM for
that matter).
YOu can also claim, based on WCAG 3.3.1 that you have to associate an
error message with a form field (3.3.1 says users must be able to
identify the erroneous field and see the error message).
As everything else, WCAG is somewhat open to interpretation.
But other content, like headings that separate section of a form do
not have to be focusable, and we rely on users of screen readers to
discover those.
This could be an interesting user study.
But, in general, I find that programmatically association errors and
tooltips to form fields, you make a difference in user experience and
really help people correctly fill in the form.
-Birkir
On 3/2/17, Dan Holbrook < = EMAIL ADDRESS REMOVED = > wrote:
> This was touched upon in the previous thread "Forms, forms mode and static
> text interaction with Jaws" but forms mode requires extra care to be taken
> in order to make sure certain information (e.g. disabled fields with data,
> field instructions, legal disclaimers) is read.
>
> In our testing of forms right now (NVDA and JAWS) we browse to the form,
> enter data in the first field, then tab through the form, which requires
> developers to attempt to make forms fully accessible to users who use
> tabbing alone for form navigation.
>
> I have talked to a few people who use browse mode to go through the form
> and used forms mode only for entry, which would make this extra work
> unnecessary. I'd like to see if there is a consensus or trend around how
> screen reader users navigate forms: do you tab through fields once in a
> form (remaining in forms mode) or do you navigate forms with a combination
> of forms mode and browsing?
>
> *Dan Holbrook**QA Engineer and Co-President
> <http://www.nerdery.com/copresident>;**The
> Nerdery**http://www.nerdery.com/people#hz <http://www.nerdery.com/Xx>;*
> > > > >
--
Work hard. Have fun. Make history.
From: JP Jamous
Date: Fri, Mar 03 2017 7:18AM
Subject: Re: Screen reader Forms Mode as Only Interaction Method?
← Previous message | Next message →
My 2 cents to this approach is that it is more of a UX convenience. I am big on UX improvement, because with proper semantic and ARIA, there is no reason why a form cannot be accessible without jumping out of forms mode.
Yes, some forms might have a large paragraph or more to provide instructions. Something like that is unavoidable However, KISS is always my preferred approach. Keep it simple, get the user to where he or she needs to be and gain that user as a future customer or loyal one.
We live in a fast world and getting something ordered or filled out should be as painless as possible. Customers appreciate that whether they have a sensory disability or not. Am I going to like or dislike someone making my life easier? Obviously like. That is why car manufacturers have different vehicles for different types of shoppers. A prime example, is the Nissan Pathfinder.
It used to be the truck or jeep to buy. Way high above the ground, can tow and has a great 3.5L engine in it. That was in the 90's. Now, it is a car chassis and only 7 inches above the ground. Its older fans walked away, but other shoppers made it the way it is now.
Families that go on long trips want more room, the power to tow a boat or other things and a smooth luxurious vehicle. That's what they have. I bought it for my wife, because she does not like high vehicles; she drives the speed limit and she has no desire in off roading. We have so much room for my guide dog and our friends and family with all the luxury and bells and whistles. For us it keeps my wife happy, while it keeps me happy as I can hook a boat in the future to it and can feel that power of a 3.5L engine. On the other hand, the Armata is now made for old Pathfinder lovers.
I know that might have sounded as if I diverted from the original thought, but I did not. Who is my primary audience, should be the question any PM should ask while in the requirement phase of the SDLC. Once those types of audiences are determined, it is a matter of having a happy medium amongst them.
I use that in my auditing as well. Who are the audiences of this site and how can I find a happy medium between all of them? I then apply that in my remediation with WCAG 2.0 in mind.
I just wanted to give my humble opinion as I have noticed that some auditors or developers tend to complicate their lives by thinking too much into it. We are not network administrators to worry about security and other factors. Our job is much simpler. It only gets complex when multiple disabilities have to be taken in consideration. That is why keeping it simple allows us to make our lives easier, while still provide the proper accessibility that customers should have.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michael Bullis
Sent: Friday, March 3, 2017 7:38 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Screenreader Forms Mode as Only Interaction Method?
I typically start in forms mode but often find that fields are not labeled clearly or correctly so jump out of forms mode to see the title of the form which is usually determinable and then fill in the information for that field.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Dan Holbrook
Sent: Thursday, March 2, 2017 1:36 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Screenreader Forms Mode as Only Interaction Method?
This was touched upon in the previous thread "Forms, forms mode and static text interaction with Jaws" but forms mode requires extra care to be taken in order to make sure certain information (e.g. disabled fields with data, field instructions, legal disclaimers) is read.
In our testing of forms right now (NVDA and JAWS) we browse to the form, enter data in the first field, then tab through the form, which requires developers to attempt to make forms fully accessible to users who use tabbing alone for form navigation.
I have talked to a few people who use browse mode to go through the form and used forms mode only for entry, which would make this extra work unnecessary. I'd like to see if there is a consensus or trend around how screen reader users navigate forms: do you tab through fields once in a form (remaining in forms mode) or do you navigate forms with a combination of forms mode and browsing?
*Dan Holbrook**QA Engineer and Co-President <http://www.nerdery.com/copresident>;**The
Nerdery**http://www.nerdery.com/people#hz <http://www.nerdery.com/Xx>;*
From: Lovely, Brian (CONT)
Date: Fri, Mar 03 2017 7:32AM
Subject: Re: Screen reader Forms Mode as Only Interaction Method?
← Previous message | Next message →
I have a related question about forms. What do you think about tooltips in forms? I'm talking specifically about little question mark icons that ask and then answer some anticipated question about the reason for asking a question or about how to go about answering the question. I have a number of problems with them:
1. I didn't even think about this previously, but I can see the value of staying in forms mode throughout the completion of a form, so a tooltip requires switching to browse mode.
2. If you think someone needs to know something, why not just put it in plain text? Why make them do a little dance with an icon to get the information?
3. They are almost never coded accessibly to start with, and they are often coded in such a way that it is harder to make them accessible than if they were designed to be accessible from the beginning.
4. They tend to be enclosed by the label element, which just seems all kind of wrong to me: <label for="ss_number>Social Security Number <a href="tooltip_javascript">Why do we need this?</a></label>
Anyone have any thoughts on tooltips in forms?
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: JP Jamous
Date: Fri, Mar 03 2017 8:56AM
Subject: Re: Screen reader Forms Mode as Only Interaction Method?
← Previous message | Next message →
1. I didn't even think about this previously, but I can see the value of staying in forms mode throughout the completion of a form, so a tooltip requires switching to browse mode.
Not all the time you have to switch to browse mode. If you use ARIA along with proper semantic, you can achieve the desired output while remaining in forms mode.
2. If you think someone needs to know something, why not just put it in plain text? Why make them do a little dance with an icon to get the information?
How can you put a link in plain text? Personally, I don't like links in a form as they are not a form element.
3. They are almost never coded accessibly to start with, and they are often coded in such a way that it is harder to make them accessible than if they were designed to be accessible from the beginning.
Welcome to HTML improper semantic.
4. They tend to be enclosed by the label element, which just seems all kind of wrong to me: <label for="ss_number>Social Security Number <a href="tooltip_javascript">Why do we need this?</a></label>
That's where I recommend for developer to segregate the link from the label. Again, if it can be done, it does not mean that it should be done. Doing it causes improper semantic.
Anyone have any thoughts on tooltips in forms?
As I stated above:
A. Ensure that the developer is using proper semantic. I cannot stress this enough. Unless the developer has a strong argument as to why improper semantic was used, I refuse to accept it.
B. Although I try to use less ARIA and more proper semantic, remember that you are in a form and the word dynamic should remain in your mind. So using some ARIA to provide a better UX is fair enough.
From: Chagnon | PubCom
Date: Fri, Mar 03 2017 10:04AM
Subject: Re: Screen reader Forms Mode as Only Interaction Method?
← Previous message | No next message
I hate our current method of creating accessible forms, and I hate the way ATs access the content for their users.
It's a convoluted mess that doesn't meet anyone's needs, neither the form's creator nor the form's user. Someone needs to rethink the process, product, and functionality from the ground up.
RE: your specific question about tooltips, they're required for accessibility but they really fail to fully inform AT users, especially blind and low-vision users, with all the information they need about the form in general and the fields themselves.
So much information is in the live body text that surrounds and precedes the form fields. It's not feasible to duplicate all of that information in the tooltips, so AT users end up getting short changed.
The only solution they have is to flip in and out of "forms" mode in their AT software, hopefully flipping to the body text at the correct time to catch the critical information that's there.
Between labels, tooltips, and the regular body text, they all compete with each other and we end up with a near useless mess of a form that takes an enormous amount of time to create and ends up having such minimal usability for the user.
Such an absurd way to create a product when you want to meet the needs of all users.
RE: your questions, "If you think someone needs to know something, why not just put it in plain text? Why make them do a little dance with an icon to get the information?"
This a basic accessibility concept we teach throughout all of our classes: stop burying information inside tags, attributes, summaries, titles, etc. Instead, KISS -- keep it simple, sweetie!
If the information is so important for someone with a disability to know about, then it's important for every other user to know about, also. Put the information in live body text so that everyone sees/hears it. The task is easy to implement, easy to edit and update, and most successful in presenting it to all AT users.
Karen McCall's book, "Accessible and Usable PDF Documents" has a section on accessible PDF forms that's the best in the industry. Contact me off list if you're interested in purchasing a copy: = EMAIL ADDRESS REMOVED =
Sorry for the Friday rant...but you hit a nerve, Brian! You asked good questions.
--Bevi Chagnon
- - -
Bevi Chagnon | www.PubCom.com
Technologists, Consultants, Trainers, Designers, and Developers
for publishing & communication
| Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
- - -
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lovely, Brian (CONT)
Sent: Friday, March 3, 2017 9:33 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Screen reader Forms Mode as Only Interaction Method?
I have a related question about forms. What do you think about tooltips in forms? I'm talking specifically about little question mark icons that ask and then answer some anticipated question about the reason for asking a question or about how to go about answering the question. I have a number of problems with them:
1. I didn't even think about this previously, but I can see the value of staying in forms mode throughout the completion of a form, so a tooltip requires switching to browse mode.
2. If you think someone needs to know something, why not just put it in plain text? Why make them do a little dance with an icon to get the information?
3. They are almost never coded accessibly to start with, and they are often coded in such a way that it is harder to make them accessible than if they were designed to be accessible from the beginning.
4. They tend to be enclosed by the label element, which just seems all kind of wrong to me: <label for="ss_number>Social Security Number <a href="tooltip_javascript">Why do we need this?</a></label>
Anyone have any thoughts on tooltips in forms?