E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: Dan Holbrook
Date: Thu, Mar 02 2017 11:36AM
Subject: Screenreader Forms Mode as Only Interaction Method?
No previous message | Next message →

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: Birkir R. Gunnarsson
Date: Thu, Mar 02 2017 12:03PM
Subject: Re: Screenreader Forms Mode as Only Interaction Method?
← Previous message | Next message →

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: Michael Bullis
Date: Fri, Mar 03 2017 6:37AM
Subject: Re: Screenreader Forms Mode as Only Interaction Method?
← Previous message | Next message →

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: Andrews, David B (DEED)
Date: Mon, Mar 06 2017 1:32PM
Subject: Re: Screenreader Forms Mode as Only Interaction Method?
← Previous message | No next message

I use a combination of Forms Mode, and browsing. I find it easier, and more reliable to go in and out of forms mode so I don't miss something.

However, I don't think I am a typical user, but there may not be such a thing, so asking here probably won't get you a definitive answer.

Dave



From: WebAIM-Forum [ = EMAIL ADDRESS REMOVED = ] on behalf of Dan Holbrook [ = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, March 02, 2017 12: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?