E-mail List Archives

Search E-mail List Archives for

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.

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.

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