E-mail List Archives

Search E-mail List Archives for

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

From: Kohn, Robbie
Date: Thu, Apr 25 2013 11:42AM
Subject: Best practices for Captivate captioning
No previous message | Next message →

The project I'm working with is using Captivate output for training. Captivate has an option of placing synchronized captions on the training screen, or in a text box underneath the training screen. For me as a hearing impaired user, when I'm taking training classes I like seeing the text in a box at the bottom, especially when there isn't much movement in the movie portion of the training.

So, for best practice purposes, should we provide synchronized captions that will overlay the screen, or should we place the text in a box underneath the screen?


Robbie Ann Kohn
Senior Consultant/Accessibility & Usability
E: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

From: Dave Merrill
Date: Mon, May 06 2013 5:24AM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

Hi folks, I have a couple of questions about labeling forms and their
fields.

1. Is it considered best practice for forms to have a title attribute, to
identify the purpose of the overall form itself? When evaluating site
accessibility, should form titles be considered at all? How else should
forms themselves be labelled? If by a header tag, should it be inside the
form, or immediately preceding it?

2. For form fields, clearly a label tag is best practice, but should a
title attribute ever be used?

Thanks!

--
Dave Merrill

From: Jared Smith
Date: Mon, May 06 2013 9:12AM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

On Mon, May 6, 2013 at 5:24 AM, Dave Merrill wrote:

> 1. Is it considered best practice for forms to have a title attribute, to
> identify the purpose of the overall form itself?

I would not recommend this practice. The title attribute would only
rarely be presented to the user - pretty much only to sighted mouse
users that hover their mouse over the form to present the mouse
tooltip. And in this case, the tooltip may be more distracting than it
would be helpful. The title would not likely be presented to
keyboard-only users, screen reader users, touch-screen device users,
etc.

> When evaluating site accessibility, should form titles be considered
> at all? How else should forms themselves be labelled?

If the form needs additional explanatory text (i.e., a "title"), then
it should be presented in text to everyone (probably in a heading). If
it doesn't, then there's no need to add something unnecessary and
extraneous to the title attribute.

> If by a header tag, should it be inside the
> form, or immediately preceding it?

I've never really considered this, but I think that inside the form
would be best. On the off-chance a user were to navigate directly to
the form, the heading (not header) would be read first.

> 2. For form fields, clearly a label tag is best practice, but should a
> title attribute ever be used?

If there's a visible label (which almost all form fields should have),
then a label element is always appropriate. If a form field's function
is apparent visibly, but label text is not present (such as an
unlabeled search box with an adjacent "Search" button"), then the
title attribute could be used to convey the function of the field to
screen reader users. The title attribute is generally read by screen
readers, but only if an associated label is NOT present.

Jared

From: Dave Merrill
Date: Mon, May 06 2013 11:09AM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

Thanks Jared, helpful.

You're saying that a field's title WILL be read if no label is present, as
in your search box example, right? If so, then in the context of an
accessibility review tool in a CMS, the logic would be:
- If there's a label with text, show it
- If not, and there's a title, show it, but suggest that there should be a
label if that's workable
- If there's neither, show both label and title as missing, suggesting that
lable should be used if that's workable

Make sense?

(You're right, I meant a heading tag for a form, not a header.)

Thanks again,
Dave Merrill


On Mon, May 6, 2013 at 11:12 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Mon, May 6, 2013 at 5:24 AM, Dave Merrill wrote:
>
> > 1. Is it considered best practice for forms to have a title attribute, to
> > identify the purpose of the overall form itself?
>
> I would not recommend this practice. The title attribute would only
> rarely be presented to the user - pretty much only to sighted mouse
> users that hover their mouse over the form to present the mouse
> tooltip. And in this case, the tooltip may be more distracting than it
> would be helpful. The title would not likely be presented to
> keyboard-only users, screen reader users, touch-screen device users,
> etc.
>
> > When evaluating site accessibility, should form titles be considered
> > at all? How else should forms themselves be labelled?
>
> If the form needs additional explanatory text (i.e., a "title"), then
> it should be presented in text to everyone (probably in a heading). If
> it doesn't, then there's no need to add something unnecessary and
> extraneous to the title attribute.
>
> > If by a header tag, should it be inside the
> > form, or immediately preceding it?
>
> I've never really considered this, but I think that inside the form
> would be best. On the off-chance a user were to navigate directly to
> the form, the heading (not header) would be read first.
>
> > 2. For form fields, clearly a label tag is best practice, but should a
> > title attribute ever be used?
>
> If there's a visible label (which almost all form fields should have),
> then a label element is always appropriate. If a form field's function
> is apparent visibly, but label text is not present (such as an
> unlabeled search box with an adjacent "Search" button"), then the
> title attribute could be used to convey the function of the field to
> screen reader users. The title attribute is generally read by screen
> readers, but only if an associated label is NOT present.
>
> Jared
> > > >



--
Dave Merrill

From: Jared Smith
Date: Mon, May 06 2013 11:58AM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

On Mon, May 6, 2013 at 11:09 AM, Dave Merrill wrote:

> You're saying that a field's title WILL be read if no label is present, as
> in your search box example, right?

Correct.

> If so, then in the context of an
> accessibility review tool in a CMS, the logic would be:
> - If there's a label with text, show it
> - If not, and there's a title, show it, but suggest that there should be a
> label if that's workable
> - If there's neither, show both label and title as missing, suggesting that
> lable should be used if that's workable

Looks good to me. If there is visible label text, it should be
associated to the control. If not, then a title attribute can be used
to describe the control. If neither, then the function of the control
will be ambiguous.

Jared

From: Denis Boudreau
Date: Mon, May 06 2013 12:07PM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

Hey guys,

I think it would be advisable to point out that for improved consistency and support with assistive technologies and user agents, relying on the aria-label attribute rather than the title attribute would be a good idea. Going back to your logic, this would translate as:

- If there's a label with text, show it
- If not, and there's an aria-label attribute, show it, but suggest that there should be a visible label (if that's workable)
- If not, and there's a title attribute, show it, but suggest that there should be either an aria-label attribute or a visible label (if that's workable)
- If there's neither, show label, aria-label and title as missing, suggesting that a visible label should be used (if that's workable)

Just a thought.

/Denis



On 2013-05-06, at 1:58 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Mon, May 6, 2013 at 11:09 AM, Dave Merrill wrote:
>
>> You're saying that a field's title WILL be read if no label is present, as
>> in your search box example, right?
>
> Correct.
>
>> If so, then in the context of an
>> accessibility review tool in a CMS, the logic would be:
>> - If there's a label with text, show it
>> - If not, and there's a title, show it, but suggest that there should be a
>> label if that's workable
>> - If there's neither, show both label and title as missing, suggesting that
>> lable should be used if that's workable
>
> Looks good to me. If there is visible label text, it should be
> associated to the control. If not, then a title attribute can be used
> to describe the control. If neither, then the function of the control
> will be ambiguous.
>
> Jared
> > >

From: Jared Smith
Date: Mon, May 06 2013 12:26PM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

On Mon, May 6, 2013 at 12:07 PM, Denis Boudreau wrote:

> I think it would be advisable to point out that for improved consistency and support with assistive technologies and user agents, relying on the aria-label attribute rather than the title attribute would be a good idea.

Are there modern user agents that do not read the title attribute if a
label is missing? I'm not aware of any. But I can think of lots of
user agents that don't support aria-label, including almost everything
over a year or so old.

I agree with you in principle - I've never been entirely comfortable
with using title as a replacement for a label. At a minimum it's an
abuse of the spirit of HTML's definition of title as being for
"advisory information". If it's inaccessible without the title, it
sounds like more than advisory to me. I do note, however, that title
has been redefined in HTML5 to include labels for interactive
controls.

If one can get the same behavior and support from a native HTML
attribute, I'd think it should be used over an ARIA attribute.

Jared

From: Dave Merrill
Date: Mon, May 06 2013 1:04PM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

Great, thanks

Dave Merrill


On Mon, May 6, 2013 at 1:58 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Mon, May 6, 2013 at 11:09 AM, Dave Merrill wrote:
>
> > You're saying that a field's title WILL be read if no label is present,
> as
> > in your search box example, right?
>
> Correct.
>
> > If so, then in the context of an
> > accessibility review tool in a CMS, the logic would be:
> > - If there's a label with text, show it
> > - If not, and there's a title, show it, but suggest that there should be
> a
> > label if that's workable
> > - If there's neither, show both label and title as missing, suggesting
> that
> > lable should be used if that's workable
>
> Looks good to me. If there is visible label text, it should be
> associated to the control. If not, then a title attribute can be used
> to describe the control. If neither, then the function of the control
> will be ambiguous.
>
> Jared
> > > >



--
Dave Merrill

From: Dave Merrill
Date: Mon, May 06 2013 1:18PM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

Good point Denis, and in theory we should honor aria-labelledby also.

However, in my context, I'm somewhat constrained, because the CMS this
belongs to isn't currently planned to have any way for content authors to
set any ARIA attributes besides landmark roles. Some version of both
attributes are on my shortlist for consideration as future features, but
I'm sure I can't get them in now.

Good idea though, thanks.

Dave Merrill


On Mon, May 6, 2013 at 2:07 PM, Denis Boudreau < = EMAIL ADDRESS REMOVED = >wrote:

> Hey guys,
>
> I think it would be advisable to point out that for improved consistency
> and support with assistive technologies and user agents, relying on the
> aria-label attribute rather than the title attribute would be a good idea.
> Going back to your logic, this would translate as:
>
> - If there's a label with text, show it
> - If not, and there's an aria-label attribute, show it, but suggest that
> there should be a visible label (if that's workable)
> - If not, and there's a title attribute, show it, but suggest that there
> should be either an aria-label attribute or a visible label (if that's
> workable)
> - If there's neither, show label, aria-label and title as missing,
> suggesting that a visible label should be used (if that's workable)
>
> Just a thought.
>
> /Denis
>
>
>
> On 2013-05-06, at 1:58 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> > On Mon, May 6, 2013 at 11:09 AM, Dave Merrill wrote:
> >
> >> You're saying that a field's title WILL be read if no label is present,
> as
> >> in your search box example, right?
> >
> > Correct.
> >
> >> If so, then in the context of an
> >> accessibility review tool in a CMS, the logic would be:
> >> - If there's a label with text, show it
> >> - If not, and there's a title, show it, but suggest that there should
> be a
> >> label if that's workable
> >> - If there's neither, show both label and title as missing, suggesting
> that
> >> lable should be used if that's workable
> >
> > Looks good to me. If there is visible label text, it should be
> > associated to the control. If not, then a title attribute can be used
> > to describe the control. If neither, then the function of the control
> > will be ambiguous.
> >
> > Jared
> > > > > > >
> > > >



--
Dave Merrill

From: Denis Boudreau
Date: Mon, May 06 2013 1:48PM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

Hi Jared,


On 2013-05-06, at 2:26 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Mon, May 6, 2013 at 12:07 PM, Denis Boudreau wrote:
>
>> I think it would be advisable to point out that for improved consistency and support with assistive technologies and user agents, relying on the aria-label attribute rather than the title attribute would be a good idea.
>
> Are there modern user agents that do not read the title attribute if a label is missing? I'm not aware of any.


Maybe my information is a bit outdated, but last time I checked (has it been two years already?!), the title attribute was only partially supported, or at the very least, not always read by default by screen readers, I just looked it up and found this post by Terrill Thompson that shows title support was still not reliable back when Jaws was on v12. Has much changed since then? http://terrillthompson.com/tests/forms_title_not_label.html


> But I can think of lots of user agents that don't support aria-label, including almost everything over a year or so old.

I would have said two years, but I agree with you. I do see much better chances at interest in improving support for aria and html5 goodies than for old HTML attributes that are way over 10 years of age. Unless it gets totally refactored in the course of the HTML5 overhauls.


> I agree with you in principle - I've never been entirely comfortable
> with using title as a replacement for a label. At a minimum it's an
> abuse of the spirit of HTML's definition of title as being for
> "advisory information". If it's inaccessible without the title, it
> sounds like more than advisory to me. I do note, however, that title
> has been redefined in HTML5 to include labels for interactive
> controls.

Right, but if we're worried about support for aria on technologies that are a few years old, then I'd be very reluctant to rely on this for now either.


> If one can get the same behavior and support from a native HTML
> attribute, I'd think it should be used over an ARIA attribute.

I do agree with you that we should always prioritize native HTML over aria, and that's certainly true in cases where native html is reliably supported. Which explains why I was advocating for the use of aria-label in this case - I don't think it is reliably supported, but I'd be happy to be shown otherwise. Maybe I need to check that out again. Things move pretty fast and it's easy to miss some of the moving parts.

Given proper support (if it's indeed the case), then I too would advise to use the title attribute first and pach with aria when all else fails. That makes sense. The reason why I prefer aria-label right now is I was confident that support was more consistent. But now that belief has been shaken. <smile>

/Denis

From: Bryan Garaventa
Date: Mon, May 06 2013 2:05PM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

One thing to keep in mind, aria-label isn't supported in iOS devices using
Voiceover. At least it wasn't as of four months ago when I tested it on
buttons and form fields. If this has changed, please let me know.

----- Original Message -----
From: "Denis Boudreau" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, May 06, 2013 11:07 AM
Subject: Re: [WebAIM] Best practices for identifying forms and their fields


> Hey guys,
>
> I think it would be advisable to point out that for improved consistency
> and support with assistive technologies and user agents, relying on the
> aria-label attribute rather than the title attribute would be a good idea.
> Going back to your logic, this would translate as:
>
> - If there's a label with text, show it
> - If not, and there's an aria-label attribute, show it, but suggest that
> there should be a visible label (if that's workable)
> - If not, and there's a title attribute, show it, but suggest that there
> should be either an aria-label attribute or a visible label (if that's
> workable)
> - If there's neither, show label, aria-label and title as missing,
> suggesting that a visible label should be used (if that's workable)
>
> Just a thought.
>
> /Denis
>
>
>
> On 2013-05-06, at 1:58 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On Mon, May 6, 2013 at 11:09 AM, Dave Merrill wrote:
>>
>>> You're saying that a field's title WILL be read if no label is present,
>>> as
>>> in your search box example, right?
>>
>> Correct.
>>
>>> If so, then in the context of an
>>> accessibility review tool in a CMS, the logic would be:
>>> - If there's a label with text, show it
>>> - If not, and there's a title, show it, but suggest that there should be
>>> a
>>> label if that's workable
>>> - If there's neither, show both label and title as missing, suggesting
>>> that
>>> lable should be used if that's workable
>>
>> Looks good to me. If there is visible label text, it should be
>> associated to the control. If not, then a title attribute can be used
>> to describe the control. If neither, then the function of the control
>> will be ambiguous.
>>
>> Jared
>> >> >> >
> > >

From: Roger Hudson
Date: Mon, May 06 2013 2:13PM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | Next message →

Hi

While I agree an explicitly associate label is always the preferable way
identify form controls this may not always be possible. I have been testing
(or asking others to test) the use of the title attribute with different
screen readers and browsers on and off since 2008, and have found it to be
well supported. My recent article "Accessible Forms 1: Labels and
identification"
(http://usability.com.au/2013/04/accessible-forms-1-labels-and-identificatio
n/) contains a video showing text input and select input in an imaginary
order form being identified with the title attribute (NVDA and Firefox).
Also a table summarising how it is supported by four different screen
readers.

Best wishes,
Roger

-----Original Message-----
From: Denis Boudreau [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, 7 May 2013 5:48 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Best practices for identifying forms and their fields

Hi Jared,


On 2013-05-06, at 2:26 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Mon, May 6, 2013 at 12:07 PM, Denis Boudreau wrote:
>
>> I think it would be advisable to point out that for improved consistency
and support with assistive technologies and user agents, relying on the
aria-label attribute rather than the title attribute would be a good idea.
>
> Are there modern user agents that do not read the title attribute if a
label is missing? I'm not aware of any.


Maybe my information is a bit outdated, but last time I checked (has it been
two years already?!), the title attribute was only partially supported, or
at the very least, not always read by default by screen readers, I just
looked it up and found this post by Terrill Thompson that shows title
support was still not reliable back when Jaws was on v12. Has much changed
since then? http://terrillthompson.com/tests/forms_title_not_label.html


> But I can think of lots of user agents that don't support aria-label,
including almost everything over a year or so old.

I would have said two years, but I agree with you. I do see much better
chances at interest in improving support for aria and html5 goodies than for
old HTML attributes that are way over 10 years of age. Unless it gets
totally refactored in the course of the HTML5 overhauls.


> I agree with you in principle - I've never been entirely comfortable
> with using title as a replacement for a label. At a minimum it's an
> abuse of the spirit of HTML's definition of title as being for
> "advisory information". If it's inaccessible without the title, it
> sounds like more than advisory to me. I do note, however, that title
> has been redefined in HTML5 to include labels for interactive
> controls.

Right, but if we're worried about support for aria on technologies that are
a few years old, then I'd be very reluctant to rely on this for now either.


> If one can get the same behavior and support from a native HTML
> attribute, I'd think it should be used over an ARIA attribute.

I do agree with you that we should always prioritize native HTML over aria,
and that's certainly true in cases where native html is reliably supported.
Which explains why I was advocating for the use of aria-label in this case -
I don't think it is reliably supported, but I'd be happy to be shown
otherwise. Maybe I need to check that out again. Things move pretty fast and
it's easy to miss some of the moving parts.

Given proper support (if it's indeed the case), then I too would advise to
use the title attribute first and pach with aria when all else fails. That
makes sense. The reason why I prefer aria-label right now is I was confident
that support was more consistent. But now that belief has been shaken.
<smile>

/Denis
messages to = EMAIL ADDRESS REMOVED =

From: Dave Merrill
Date: Mon, May 06 2013 2:41PM
Subject: Re: Best practices for identifying forms and their fields
← Previous message | No next message

Related, is it considered bad accessibility practice to have controls that
aren't inside a form? Modern scripted interactions sometimes don't need
one, since they either don't post to a server at all, or do so via Ajax.

It would seem not to be required, if the form itself isn't really seen by
readers, so its purpose has to be stated as readable text.

Thanks,
Dave Merrill


On Mon, May 6, 2013 at 4:13 PM, Roger Hudson < = EMAIL ADDRESS REMOVED = >wrote:

> Hi
>
> While I agree an explicitly associate label is always the preferable way
> identify form controls this may not always be possible. I have been testing
> (or asking others to test) the use of the title attribute with different
> screen readers and browsers on and off since 2008, and have found it to be
> well supported. My recent article "Accessible Forms 1: Labels and
> identification"
> (
> http://usability.com.au/2013/04/accessible-forms-1-labels-and-identificatio
> n/) contains a video showing text input and select input in an imaginary
> order form being identified with the title attribute (NVDA and Firefox).
> Also a table summarising how it is supported by four different screen
> readers.
>
> Best wishes,
> Roger
>
> -----Original Message-----
> From: Denis Boudreau [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Tuesday, 7 May 2013 5:48 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Best practices for identifying forms and their fields
>
> Hi Jared,
>
>
> On 2013-05-06, at 2:26 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> > On Mon, May 6, 2013 at 12:07 PM, Denis Boudreau wrote:
> >
> >> I think it would be advisable to point out that for improved consistency
> and support with assistive technologies and user agents, relying on the
> aria-label attribute rather than the title attribute would be a good idea.
> >
> > Are there modern user agents that do not read the title attribute if a
> label is missing? I'm not aware of any.
>
>
> Maybe my information is a bit outdated, but last time I checked (has it
> been
> two years already?!), the title attribute was only partially supported, or
> at the very least, not always read by default by screen readers, I just
> looked it up and found this post by Terrill Thompson that shows title
> support was still not reliable back when Jaws was on v12. Has much changed
> since then? http://terrillthompson.com/tests/forms_title_not_label.html
>
>
> > But I can think of lots of user agents that don't support aria-label,
> including almost everything over a year or so old.
>
> I would have said two years, but I agree with you. I do see much better
> chances at interest in improving support for aria and html5 goodies than
> for
> old HTML attributes that are way over 10 years of age. Unless it gets
> totally refactored in the course of the HTML5 overhauls.
>
>
> > I agree with you in principle - I've never been entirely comfortable
> > with using title as a replacement for a label. At a minimum it's an
> > abuse of the spirit of HTML's definition of title as being for
> > "advisory information". If it's inaccessible without the title, it
> > sounds like more than advisory to me. I do note, however, that title
> > has been redefined in HTML5 to include labels for interactive
> > controls.
>
> Right, but if we're worried about support for aria on technologies that are
> a few years old, then I'd be very reluctant to rely on this for now either.
>
>
> > If one can get the same behavior and support from a native HTML
> > attribute, I'd think it should be used over an ARIA attribute.
>
> I do agree with you that we should always prioritize native HTML over aria,
> and that's certainly true in cases where native html is reliably supported.
> Which explains why I was advocating for the use of aria-label in this case
> -
> I don't think it is reliably supported, but I'd be happy to be shown
> otherwise. Maybe I need to check that out again. Things move pretty fast
> and
> it's easy to miss some of the moving parts.
>
> Given proper support (if it's indeed the case), then I too would advise to
> use the title attribute first and pach with aria when all else fails. That
> makes sense. The reason why I prefer aria-label right now is I was
> confident
> that support was more consistent. But now that belief has been shaken.
> <smile>
>
> /Denis
> > > messages to = EMAIL ADDRESS REMOVED =
>
> > > >



--
Dave Merrill