E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Accessible form field hint text

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

From: Denise
Date: Mon, Jun 24 2013 6:38AM
Subject: Accessible form field hint text
No previous message | Next message →

Hi,
I am trying to make my form more accessible and could really use some advice, and guidance as to best practice.

Currently we have some hint/help text that is displayed (using Javascript to set the style to block) when the input gets focus. The help text is in a div after the input field.

In some cases there are two input fields next to each other e.g. for a date but both sets of hints are after both inputs, i.e. input month, input year, help text month, help text year.
This means that the help text month can't be read by the screen reader using the keyboard as the focus goes to the year input.

My main concerns:
* reliance on Javascript
* no association between the help text and the form input
* screen reader not being able to read out help text for first of multiple input when using keyboard due to positioning in html
* does a screen reader user expect to switch between focus mode to text reading mode after each input?
* should we just have one help text for the month/year combined.

Thanks in advance for your help

From: Birkir R. Gunnarsson
Date: Mon, Jun 24 2013 7:15AM
Subject: Re: Accessible form field hint text
← Previous message | Next message →

Hi

aria-describedby is definitely your friend in this type of situation.
You can associate the hint text with the input field using
aria-descirbedby, and most, if not all, screen readers will read it
automatically when that field receives focus (well, older versions of
the major screen readers still will not do this, just keep that in
mind).
You could create a tabindex on the helptext so a user tabbing through
the form will actually read it, though you have to manipulate the
tabindex to come before the edit field,, as an alternative (or along
with thte aria-descirbedby), but it might confuse some users since
they associated tabable item with an actionable item.
Finally you could splice the description into the label for the input
field, for instance, by hiding it off-screen with css but then adding
it with a span with class invissible to the form label. That way the
text is read out to screen reader users, but it does not create any
additional visual distractions.
(remember to hide text you must position it off-screen,
vissibility:hidden or display:none hides text for everyone, including
screen readers).
Most screen reader users do get out of tabbing/forms mode when
exploring and filling in forms, and look around the field with arrow
keys if something is not clear.
hth
-B

On 6/24/13, Denise < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
> I am trying to make my form more accessible and could really use some
> advice, and guidance as to best practice.
>
> Currently we have some hint/help text that is displayed (using Javascript to
> set the style to block) when the input gets focus. The help text is in a div
> after the input field.
>
> In some cases there are two input fields next to each other e.g. for a date
> but both sets of hints are after both inputs, i.e. input month, input year,
> help text month, help text year.
> This means that the help text month can't be read by the screen reader using
> the keyboard as the focus goes to the year input.
>
> My main concerns:
> * reliance on Javascript
> * no association between the help text and the form input
> * screen reader not being able to read out help text for first of multiple
> input when using keyboard due to positioning in html
> * does a screen reader user expect to switch between focus mode to text
> reading mode after each input?
> * should we just have one help text for the month/year combined.
>
> Thanks in advance for your help
>
>
> > > >

From: Patrick H. Lauke
Date: Mon, Jun 24 2013 7:25AM
Subject: Re: Accessible form field hint text
← Previous message | Next message →

On 24/06/2013 13:38, Denise wrote:
> Hi, I am trying to make my form more accessible and could really use
> some advice, and guidance as to best practice.
>
> Currently we have some hint/help text that is displayed (using
> Javascript to set the style to block) when the input gets focus. The
> help text is in a div after the input field.
>
> In some cases there are two input fields next to each other e.g. for
> a date but both sets of hints are after both inputs, i.e. input
> month, input year, help text month, help text year. This means that
> the help text month can't be read by the screen reader using the
> keyboard as the focus goes to the year input.
>
> My main concerns: * reliance on Javascript

I'd say have it so it's shown by default, and on page load (if JS is
present) hide it and hook in the show/hide functionality. Or just have
it always visible.

> * no association between the help text and the form input

I'd suggest using aria-describedby to include additional label info to a
field, e.g.

<label for="foo">Primary label</label>
<input type="text" id="foo" name="bar" aria-describedby="foo-additional">
<div id="foo-additional">Secondary label/instructions</div>

This should work in all current screenreaders. Note though that IE8
doesn't seem to support this ARIA attribute. It also doesn't support
multiple IDs on aria-labelledby, so that approach can't be used either.
In worst case, use a technique that accessibly hides content via CSS,
and add that info to the primary label itself, e.g.

<label for="foo">Primary label -
secondary label/instructions</label>
<input type="text" id="foo" name="bar">

> * screen reader not being able to read out help text for first of
> multiple input when using keyboard due to positioning in html * does
> a screen reader user expect to switch between focus mode to text
> reading mode after each input?

Ideally, no. Once a user is in forms mode, they should get all relevant
info while being in that mode through correct association of the form
controls with any labels and instructions.

--
Patrick H. Lauke

From: Jennifer Sutton
Date: Mon, Jun 24 2013 11:09AM
Subject: Re: Accessible form field hint text
← Previous message | Next message →

There's a great five-part series of posts by Roger Hudson, with
demos, that covers many aspects of form implementation.

While I know that others have addressed the specific questions
raised, I thought I'd post the link to the first part of the series
in case those on the list haven't seen it and/or in case other
specific questions arise.

Start at:

Accessible Forms 1 Labels and identification Web Usability
http://usability.com.au/2013/04/accessible-forms-1-labels-and-identification/

There are links to all of the parts from that first page.

Jennifer

From: leicestertiger@yahoo.co.uk
Date: Mon, Jun 24 2013 11:55AM
Subject: Re: Accessible form field hint text
← Previous message | Next message →

Thanks everyone, some really useful stuff.  We have to support some old browsers like ie6, can I still use the aria describedby property? Would it just ignore it or cause errors? Thanks <hr align="left" style="width:75%">On 24 Jun 2013 18:10, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote: There's a great five-part series of posts by Roger Hudson, with
 demos, that covers many aspects of form implementation.
 
 While I know that others have addressed the specific questions
 raised, I thought I'd post the link to the first part of the series
 in case those on the list haven't seen it and/or in case other
 specific questions arise.
 
 Start at:
 
 
 Accessible Forms 1 Labels and identification Web Usability
 http://usability.com.au/2013/04/accessible-forms-1-labels-and-identification/
 
 There are links to all of the parts from that first page.
 
 Jennifer

From: Birkir R. Gunnarsson
Date: Mon, Jun 24 2013 12:07PM
Subject: Re: Accessible form field hint text
← Previous message | No next message

It would not work for older browsers (IE does not support
aria-describedby prior to IE8 I believe, Jaws does not support it
prior to Jaws 9 or 10, Firefox prior to v3.6 does not support any
ARIA).
For the very old browsers you may just need to consider injecting all
messages into the labels on the form field, you can use invisible text
for the benefit of screen readers as discussed above,, the move focus
to the offending input field with JavaScript.
If user agent does not support or run JavaScript .. well, you may have
to mail them an accessible stone tablet *grin*.
No, at least, if you have all the error messages in the form field
labels, but you cannot manipulate the user focus, I think that is a
reasonable accommodation.
Cheers
-B
p.s. second Jennifer's recommendation - excellent series, I need to go
back and read it again in fact.

On 6/24/13, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks everyone, some really useful stuff.
> We have to support some old browsers like ie6, can I still use the aria
> describedby property? Would it just ignore it or cause errors?
>
> Thanks
>
>
>
> > On 24 Jun 2013 18:10, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> There's a great five-part series of posts by Roger Hudson, with
> demos, that covers many aspects of form implementation.
>
> While I know that others have addressed the specific questions
> raised, I thought I'd post the link to the first part of the series
> in case those on the list haven't seen it and/or in case other
> specific questions arise.
>
> Start at:
>
>
> Accessible Forms 1 Labels and identification Web Usability
> http://usability.com.au/2013/04/accessible-forms-1-labels-and-identification/
>
> There are links to all of the parts from that first page.
>
> Jennifer
>
> > >