WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screenreader Forms Mode as Only Interaction Method?

for

From: Birkir R. Gunnarsson
Date: Mar 2, 2017 12:03PM

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.