WebAIM - Web Accessibility In Mind

E-mail List Archives

Screen reader Forms Mode as Only Interaction Method?

for

From: Tim Harshbarger
Date: Mar 2, 2017 2:43PM

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 REMOVED> ] On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, March 02, 2017 1:04 PM
To: WebAIM Discussion List < <EMAIL 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 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.