E-mail List Archives
Thread: "Evil" code (was using title attribute as form field label)
Number of posts in this thread: 22 (In chronological order)
From: John Foliot
Date: Mon, Nov 07 2011 6:42PM
Subject: "Evil" code (was using title attribute as form field label)
No previous message | Next message →
As a follow on, the following evil code works just great in Firefox 7
using JAWS 12 (had to test it before I left the office):
<form action="">
<table role="presentation">
<tr>
<td><span id="bar">Birthday</span></td>
<td><input type="text" name="day" size="2" aria-labelledby="bar
day"> / </td>
<td><input type="text" name="month" size="2" aria-labelledby="bar
month"> / </td>
<td><input type="text" name="year" size="4" aria-labelledby="bar
year"></td>
</tr>
<tr>
<td></td>
<td><span id="day" aria-label="day as a 2 digit
value">DD</span></td>
<td><span id="month" aria-label="month as a 2 digit
value">MM</span></td>
<td><span id="year" aria-label="year as a 4 digit
value">YYYY</span></td>
</tr>
</table>
<input type="submit" value="Go">
</form>
JF
From: GILLENWATER, ZOE M
Date: Tue, Nov 08 2011 7:33AM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
Hi John,
Yes, there are thankfully lots of ways nowadays to address these situations where the one label-one field setup won't work! I guess what I'm trying to get at is, is it OK to recommend the title attribute as the technique of "first resort"? So far I haven't heard anything against it *in general* (yes, won't work or isn't best in particular use cases) so I'm going to say yes, it's OK. :-)
One thing I have noticed with using the title attribute on form fields is that, while it is read exactly like a label in forms reading mode, it is sometimes read differently than a label in normal reading mode. I haven't tested this extensively, but in some screen reader and browser combos the field with the title attribute won't be announced at all when in the normal reading mode, or the field will be announced but not its title. In forms reading mode, I haven't had any problems getting both the field and its title announced. So I guess this is one of the disadvantages of using title: the user may never know a field is there when in normal reading mode, so they'll never know to go into forms mode, where they would hear the field.
Thanks,
Zoe
Zoe Gillenwater
Technical Architect, Design Standards Accessibility
Creative Experience Team
AT&T eCommerce
o: 919-241-4083
e: = EMAIL ADDRESS REMOVED =
This e-mail, and any attachments, are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of AT&T. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 919-241-4083 and permanently delete the original and any copy thereof.
From: Sailesh Panchang
Date: Tue, Nov 08 2011 7:39AM
Subject: Re: "Evil" code (was using title attribute as form field label)
← Previous message | Next message →
John,
As per current documentation H91 of WCAG2
(http://www.w3.org/TR/WCAG20-TECHS/H91.html)
name is only exposed by label or title attribute.
JAWS 12/13 with FF7: reads aria-labelledby with content of TD and
ignores aria-label
NVDA reads aria-label.
With IE9 results are unsatisfactory
Aria-label text is available only to AT users that support it ... if
it is help text it is not available to all.
In this case maybe plain label association will work fine:
markup 'birthday' and 'dd' as label and associate it with text field for DD
Use one to one association for MM and YYYY fields.
This will work with wider set of browsers and AT.
Alternatively use title attribute where label cannot be used.
Else it may fail SC 4.1.2.
I say use ARIA only where nothing else works.
Sailesh Panchang
On 11/7/11, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> As a follow on, the following evil code works just great in Firefox 7
> using JAWS 12 (had to test it before I left the office):
>
> <form action="">
> <table role="presentation">
> <tr>
> <td><span id="bar">Birthday</span></td>
> <td><input type="text" name="day" size="2" aria-labelledby="bar
> day"> / </td>
> <td><input type="text" name="month" size="2" aria-labelledby="bar
> month"> / </td>
> <td><input type="text" name="year" size="4" aria-labelledby="bar
> year"></td>
> </tr>
> <tr>
> <td></td>
> <td><span id="day" aria-label="day as a 2 digit
> value">DD</span></td>
> <td><span id="month" aria-label="month as a 2 digit
> value">MM</span></td>
> <td><span id="year" aria-label="year as a 4 digit
> value">YYYY</span></td>
> </tr>
> </table>
> <input type="submit" value="Go">
> </form>
>
> JF
>
From: GILLENWATER, ZOE M
Date: Tue, Nov 08 2011 7:45AM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
Thanks Vincent, that's a consideration with the title attribute I hadn't thought of.
Zoe
Zoe Gillenwater
Technical Architect, Design Standards Accessibility
Creative Experience Team
AT&T eCommerce
o: 919-241-4083
e: = EMAIL ADDRESS REMOVED =
This e-mail, and any attachments, are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of AT&T. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 919-241-4083 and permanently delete the original and any copy thereof.
From: GILLENWATER, ZOE M
Date: Tue, Nov 08 2011 8:39AM
Subject: Re: "Evil" code (was using title attribute as form field label)
← Previous message | Next message →
Yeah, this won't have good enough support to be used in most real-world cases right now. But it's a good preview of what's to come! That's some clever markup there, John. :-)
One question just out of curiosity, John: Does JAWS read "birthday day as a 2 digit value DD" (for example, for the "day" field) or just "birthday day as a 2 digit value"?
Thanks,
Zoe
Zoe Gillenwater
Technical Architect, Design Standards Accessibility
Creative Experience Team
AT&T eCommerce
o: 919-241-4083
e: = EMAIL ADDRESS REMOVED =
This e-mail, and any attachments, are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of AT&T. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 919-241-4083 and permanently delete the original and any copy thereof.
From: Jared Smith
Date: Tue, Nov 08 2011 8:57AM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
I have several concerns over the use of the title attribute value for
labeling controls:
- It shouldn't be used if a visible text label is present on the page.
<label> should be used instead - it works in old browsers, and also
provides enhanced mouse accessibility, primarily for users with motor
disabilities.
- As defined in the HTML spec, title attribute is for "advisory
information". If a form field is inaccessible without the title
attribute value, this sure sounds like more than "advisory
information".
- There's nothing in HTML or accessibility specifications that tell AT
to use the title attribute as a label replacement. They just happen to
do this on their own. This behavior is really no different than IE
showing alt text in tooltips which everyone railed against as being a
violation of the spec. It makes me uncomfortable relying on the
non-standard quirks of screen readers for accessibility. As has been
noted, different screen readers treat the presentation of title
differently - and understandably so because a standard behavior is not
documented anywhere because the attribute is not even intended to work
this way.
With all of this said, it works relatively well. It just makes me
squirm a little bit. I tend to use off-screen <label> to ensure
accessibility in these situations.
Jared
From: John Foliot
Date: Tue, Nov 08 2011 10:03AM
Subject: Re: "Evil" code (was using title attribute as form field label)
← Previous message | Next message →
Sailesh Panchang wrote:
>
> John,
> As per current documentation H91 of WCAG2
> (http://www.w3.org/TR/WCAG20-TECHS/H91.html)
> name is only exposed by label or title attribute.
Hi Sailesh,
The most important thing about the Techniques for Success Criteria
attached to WCAG2 is that they are not mandated techniques, they are
"suggestions" on how to satisfy the larger need. There is already
discussion about how those documents need a refresh to add new techniques,
such as advances in ARIA and emergent HTML5 solutions: for example, in
HTML5 <input required> maps directly to <input aria-required="true"> with
regard to the Accessibility APIs and for the most part this is already
widely supported in AT.
I was very clear in my code examples that further testing was required,
and would likely leave older AT behind. What I fear however is that
developers will not try new code techniques with the emergent solutions
based upon fear of leaving some behind (a real concern) or a slavish
adherence to the Techniques document as "the only way" to solve the
problem (another big concern, but for other reasons). While I certainly
appreciate that first argument, I have little patience for the second one
- if we don't experiment and try new things we will never get to a better
experience for our users.
Remember always, the end user-experience is what we are after, not ticking
off a series of success criteria checkboxes.
> JAWS 12/13 with FF7: reads aria-labelledby with content of TD and
> ignores aria-label
I need to recheck that when I get to the office: by my quick test the
user-experience with JAWS12/FF7 was as I expected.
> NVDA reads aria-label.
I will send the code example (valid BTW per W3C specs) to Jamie and Mick
and see what they say/think.
> With IE9 results are unsatisfactory
I will send the code example along to my contacts in the IE team at
Microsoft
> Aria-label text is available only to AT users that support it ... if
> it is help text it is not available to all.
I am not sure what you mean here: yes, aria-label is string text and does
not support html rich text (if that is what you mean), and so it is not
intended for "Help" text: it maps to the Accessible Name in the
Accessibility APIs.
What we need to remember is this: any time text is not visible on the
screen, and is associated to an ARIA attribute, the accessibility APIs
will flatten that text to string text - this is not a browser function but
rather a function of the APIs. Put another way, <foo aria-label="<span
lang="fr">le widget fantastique</span>"></foo> will not preserve the
markup and instead read that aloud as a text string. (This BTW is the
number one reason why aria-describedby, pointing to text off-screen, is
not a functional replacement for @longdesc, so yes, I've done tons of
research about this in the past). There is currently no aria attribute
that will preserve markup that is not on screen: there is work on a new
attribute (aria-describedat) that will support a URL/idref (link)
off-screen as an emergent functional replacement for @longdesc - the idea
being that someday down the road we *WILL* be able to let go of @longdesc
for a superior solution. However, that day is far down the road and in no
way is a justification for killing of @longdesc at this time.
> In this case maybe plain label association will work fine:
> markup 'birthday' and 'dd' as label and associate it with text field
> for DD
This doesn't work: you can only do a direct 1-to-1 association with label:
is the form input "birthday" or "DD" (and what exactly is a DD?) I chose
my code example carefully (believe it or not <grin>), as this has always
been a problem that bugged me: when I write <label for="foo">YYYY</label>
<input id="foo"> what screen readers deliver is: "why why why why" - I
know that most users today have figured this out already, but is it really
the user experience we want? In my example, the aria-describedby
concatenates both the first value (Birthday) and the second bit of string
text (year as a 4 digit value), so that the appropriate behavior of a
screen reader should be: "Birthday year as a 4 digit value". I ask you,
which is the better user-experience?
> Use one to one association for MM and YYYY fields.
> This will work with wider set of browsers and AT.
> Alternatively use title attribute where label cannot be used.
> Else it may fail SC 4.1.2.
I am *very concerned* about using Success Criteria as the new tick-boxes
for accessibility. This is a very disconcerting and dangerous path
forward. Let's examine that Success Criteria in more detail:
"4.1.2 Name, Role, Value: For all user interface components (including
but not limited to: form elements, links and components generated by
scripts), the name and role can be programmatically determined; states,
properties, and values that can be set by the user can be programmatically
set; and notification of changes to these items is available to user
agents, including assistive technologies. (Level A)"
http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html
For the sake of this discussion, the key bit is that for form inputs "...
the name and role can be programmatically determined;". Using perfectly
valid markup code, my example *does* satisfy that statement: each form
input has been marked-up so that it can be properly determined
programmatically.
THE REAL PROBLEM TODAY IS THAT USER AGENTS HAVE NOT YET CAUGHT UP to the
newer techniques, such as what I proposed. This however does not mean that
my code fails SC 4.1.2. - rather it is the AT that fails this. I'm not
saying this isn't a real problem, but I am saying that if you failed my
code example by quoting SC 4.1.2. you are wrong because I have provided a
programmatic means of associating the name and role to each form input,
using valid (W3C) markup code.
> I say use ARIA only where nothing else works.
...and I say use ARIA everywhere you can (even if poorly supported today),
and if there are older techniques that also deliver the required
functionality use them too. I call this the belt-and-suspenders approach.
We have a chicken and egg problem, and it is only with continued and
increased usage of ARIA that the tools will get better. This is in many
ways the same problem we had back in the early 00's, when we were urging
folks to move away from table-based layouts to using CSS instead, but the
browser support for CSS wasn't there. Yet if we didn't persevere then we
would have never gotten to the point of eradicating table-based layout
pain (unless of course you enjoyed tables inside of tables inside of
tables inside of tables...)
JF
From: Sailesh Panchang
Date: Tue, Nov 08 2011 1:48PM
Subject: Re: "Evil" code (was using title attribute as form field label)
← Previous message | Next message →
Hello John,
John:In my example, the aria-describedby concatenates both the first
value (Birthday) and the second bit of string text (year as a 4 digit
value), so that the appropriate behavior of a
screen reader should be: "Birthday year as a 4 digit value". I ask you,
which is the better user-experience?
Sailesh: The aria-label text 'year as a 4 digit value' is only
available to users whose AT supports the attribute.
Not to everyone.
Sure this is better, then why not make it available to all? ... as
regular visible text that can be made a label for instance.
At the minimum, the AT-user should at least get the on-screen text
that is available to everyone and that text should be programatically
determined. Can't help if it is "YYYY".
I am called upon to test / certify and people want to do the minimum
and ask ' will this pass'?
So I am concerned with what the standards / guidelines / SC say and
indeed need to check them off one by one.
And I do have to consider what today's user agents (browsers and AT)
do. I am all for innovation but the Web page should work here and now
and allow users to perform the task they set out to do efficiently.
John: This doesn't work: you can only do a direct 1-to-1 association
with label:...
Sailesh: That's not true. More than label can point to one form
control. The 'for' of the labels will point to one 'id' of a form
control.
And this works fine with FF (with JAWS and NVDA) and has been like
this for a while. Alas but does notw ork with IE 7/8/9.
So I suggested make 'Birthday' and 'DD' as labels for the INPUT for
2-digit date.
The label 'Birthday' will convey context and many users will be ok
with it being read once.
This is akin to what screen reader users experience when reading
fieldset/legend or colspan cells with TH.
I'd like to talk if you wish (703-225-0380 ext 105)
Thanks,
Sailesh Panchang
Deque Systems
On 11/8/11, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> Sailesh Panchang wrote:
>>
>> John,
>> As per current documentation H91 of WCAG2
>> (http://www.w3.org/TR/WCAG20-TECHS/H91.html)
>> name is only exposed by label or title attribute.
>
> Hi Sailesh,
>
> The most important thing about the Techniques for Success Criteria
> attached to WCAG2 is that they are not mandated techniques, they are
> "suggestions" on how to satisfy the larger need. There is already
> discussion about how those documents need a refresh to add new techniques,
> such as advances in ARIA and emergent HTML5 solutions: for example, in
> HTML5 <input required> maps directly to <input aria-required="true"> with
> regard to the Accessibility APIs and for the most part this is already
> widely supported in AT.
>
> I was very clear in my code examples that further testing was required,
> and would likely leave older AT behind. What I fear however is that
> developers will not try new code techniques with the emergent solutions
> based upon fear of leaving some behind (a real concern) or a slavish
> adherence to the Techniques document as "the only way" to solve the
> problem (another big concern, but for other reasons). While I certainly
> appreciate that first argument, I have little patience for the second one
> - if we don't experiment and try new things we will never get to a better
> experience for our users.
>
> Remember always, the end user-experience is what we are after, not ticking
> off a series of success criteria checkboxes.
>
>
>> JAWS 12/13 with FF7: reads aria-labelledby with content of TD and
>> ignores aria-label
>
> I need to recheck that when I get to the office: by my quick test the
> user-experience with JAWS12/FF7 was as I expected.
>
>
>> NVDA reads aria-label.
>
> I will send the code example (valid BTW per W3C specs) to Jamie and Mick
> and see what they say/think.
>
>
>> With IE9 results are unsatisfactory
>
> I will send the code example along to my contacts in the IE team at
> Microsoft
>
>
>> Aria-label text is available only to AT users that support it ... if
>> it is help text it is not available to all.
>
> I am not sure what you mean here: yes, aria-label is string text and does
> not support html rich text (if that is what you mean), and so it is not
> intended for "Help" text: it maps to the Accessible Name in the
> Accessibility APIs.
>
> What we need to remember is this: any time text is not visible on the
> screen, and is associated to an ARIA attribute, the accessibility APIs
> will flatten that text to string text - this is not a browser function but
> rather a function of the APIs. Put another way, <foo aria-label="<span
> lang="fr">le widget fantastique</span>"></foo> will not preserve the
> markup and instead read that aloud as a text string. (This BTW is the
> number one reason why aria-describedby, pointing to text off-screen, is
> not a functional replacement for @longdesc, so yes, I've done tons of
> research about this in the past). There is currently no aria attribute
> that will preserve markup that is not on screen: there is work on a new
> attribute (aria-describedat) that will support a URL/idref (link)
> off-screen as an emergent functional replacement for @longdesc - the idea
> being that someday down the road we *WILL* be able to let go of @longdesc
> for a superior solution. However, that day is far down the road and in no
> way is a justification for killing of @longdesc at this time.
>
>
>
>> In this case maybe plain label association will work fine:
>> markup 'birthday' and 'dd' as label and associate it with text field
>> for DD
>
> This doesn't work: you can only do a direct 1-to-1 association with label:
> is the form input "birthday" or "DD" (and what exactly is a DD?) I chose
> my code example carefully (believe it or not <grin>), as this has always
> been a problem that bugged me: when I write <label for="foo">YYYY</label>
> <input id="foo"> what screen readers deliver is: "why why why why" - I
> know that most users today have figured this out already, but is it really
> the user experience we want? In my example, the aria-describedby
> concatenates both the first value (Birthday) and the second bit of string
> text (year as a 4 digit value), so that the appropriate behavior of a
> screen reader should be: "Birthday year as a 4 digit value". I ask you,
> which is the better user-experience?
>
>
>> Use one to one association for MM and YYYY fields.
>> This will work with wider set of browsers and AT.
>> Alternatively use title attribute where label cannot be used.
>> Else it may fail SC 4.1.2.
>
> I am *very concerned* about using Success Criteria as the new tick-boxes
> for accessibility. This is a very disconcerting and dangerous path
> forward. Let's examine that Success Criteria in more detail:
>
> "4.1.2 Name, Role, Value: For all user interface components (including
> but not limited to: form elements, links and components generated by
> scripts), the name and role can be programmatically determined; states,
> properties, and values that can be set by the user can be programmatically
> set; and notification of changes to these items is available to user
> agents, including assistive technologies. (Level A)"
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html
>
> For the sake of this discussion, the key bit is that for form inputs "...
> the name and role can be programmatically determined;". Using perfectly
> valid markup code, my example *does* satisfy that statement: each form
> input has been marked-up so that it can be properly determined
> programmatically.
>
> THE REAL PROBLEM TODAY IS THAT USER AGENTS HAVE NOT YET CAUGHT UP to the
> newer techniques, such as what I proposed. This however does not mean that
> my code fails SC 4.1.2. - rather it is the AT that fails this. I'm not
> saying this isn't a real problem, but I am saying that if you failed my
> code example by quoting SC 4.1.2. you are wrong because I have provided a
> programmatic means of associating the name and role to each form input,
> using valid (W3C) markup code.
>
>
>> I say use ARIA only where nothing else works.
>
> ...and I say use ARIA everywhere you can (even if poorly supported today),
> and if there are older techniques that also deliver the required
> functionality use them too. I call this the belt-and-suspenders approach.
>
> We have a chicken and egg problem, and it is only with continued and
> increased usage of ARIA that the tools will get better. This is in many
> ways the same problem we had back in the early 00's, when we were urging
> folks to move away from table-based layouts to using CSS instead, but the
> browser support for CSS wasn't there. Yet if we didn't persevere then we
> would have never gotten to the point of eradicating table-based layout
> pain (unless of course you enjoyed tables inside of tables inside of
> tables inside of tables...)
>
> JF
>
>
>
>
From: James Nurthen
Date: Tue, Nov 08 2011 2:18PM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
On Tue, Nov 8, 2011 at 07:56, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> - There's nothing in HTML or accessibility specifications that tell AT
> to use the title attribute as a label replacement. They just happen to
> do this on their own. This behavior is really no different than IE
> showing alt text in tooltips which everyone railed against as being a
> violation of the spec. It makes me uncomfortable relying on the
> non-standard quirks of screen readers for accessibility. As has been
> noted, different screen readers treat the presentation of title
> differently - and understandably so because a standard behavior is not
> documented anywhere because the attribute is not even intended to work
> this way.
>
>
> Jared,
This used to be the case, but the ARIA accessible name calculation does now
define title as being a valid fallback mechanism if nothing else has been
provided (see 2D of the Text Alternative
Calculation<http://www.w3.org/TR/wai-aria/roles#namecalculation>;).
Regards,
James
From: Nancy Johnson
Date: Tue, Nov 08 2011 2:39PM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
I did have a situation before WAI-ARIA where I was doing a 508 check
on an older site. There was an instance where there was a form that
the user selected one component from a select box, if they wanted to
use multiple components, the user clicked on an "Add Component"
button, the selectbox and all the html, label etc were dynamically
copied.
I could not put a unique label in the form, and there was no budget
money to update the javascript... I did find that I could use the
title attribute. http://www.w3.org/TR/WCAG20-TECHS/H65 If there was
no other way, and this was the closest I could come..
Nancy
On Tue, Nov 8, 2011 at 4:15 PM, James Nurthen < = EMAIL ADDRESS REMOVED = > wrote:
> On Tue, Nov 8, 2011 at 07:56, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
>>
>>
>> - There's nothing in HTML or accessibility specifications that tell AT
>> to use the title attribute as a label replacement. They just happen to
>> do this on their own. This behavior is really no different than IE
>> showing alt text in tooltips which everyone railed against as being a
>> violation of the spec. It makes me uncomfortable relying on the
>> non-standard quirks of screen readers for accessibility. As has been
>> noted, different screen readers treat the presentation of title
>> differently - and understandably so because a standard behavior is not
>> documented anywhere because the attribute is not even intended to work
>> this way.
>>
>>
>> Jared,
> This used to be the case, but the ARIA accessible name calculation does now
> define title as being a valid fallback mechanism if nothing else has been
> provided (see 2D of the Text Alternative
> Calculation<http://www.w3.org/TR/wai-aria/roles#namecalculation>;).
>
> Regards,
> James
>
From: Steve Faulkner
Date: Tue, Nov 08 2011 2:57PM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
Hi Jared,
you wrote:
>There's nothing in HTML or accessibility specifications that tell AT
>to use the title attribute as a label replacement.
Besides what James has pointed out (ARIA implementation guide), it should
be noted that there is no specification that tells user agents how many
HTML features should be mapped and/or interpreted by the accessibility
layer, thats what the HTML to Platform Accessibility APIs Implementation
Guide
http://dev.w3.org/html5/html-api-map/overview.html is starting to document.
Note in the section titled accessible name and description calculation (
http://dev.w3.org/html5/html-api-map/overview.html#calc) the title
attribute is included in accessible name calculation. The main reason for
this is that every browser maps the title attribute to the accessible name
property in every accessibility API and have done so for many versions ( i
would suggest for as long as they have had accessibility support).
For AT that use information exposed via an accessibility API, it is the
accessible name property they use regardless of whether the source of the
name is from the label element, aria attribute, element content or title
attribute.
regards
Stevef
On 8 November 2011 15:56, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> I have several concerns over the use of the title attribute value for
> labeling controls:
>
> - It shouldn't be used if a visible text label is present on the page.
> <label> should be used instead - it works in old browsers, and also
> provides enhanced mouse accessibility, primarily for users with motor
> disabilities.
>
> - As defined in the HTML spec, title attribute is for "advisory
> information". If a form field is inaccessible without the title
> attribute value, this sure sounds like more than "advisory
> information".
>
> - There's nothing in HTML or accessibility specifications that tell AT
> to use the title attribute as a label replacement. They just happen to
> do this on their own. This behavior is really no different than IE
> showing alt text in tooltips which everyone railed against as being a
> violation of the spec. It makes me uncomfortable relying on the
> non-standard quirks of screen readers for accessibility. As has been
> noted, different screen readers treat the presentation of title
> differently - and understandably so because a standard behavior is not
> documented anywhere because the attribute is not even intended to work
> this way.
>
>
> With all of this said, it works relatively well. It just makes me
> squirm a little bit. I tend to use off-screen <label> to ensure
> accessibility in these situations.
>
> Jared
>
From: Vincent Young
Date: Tue, Nov 08 2011 3:48PM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
John your implementation is pretty sexy. Lots of different ways to go
about this. I had some fun with it and came up with my own implementation:
http://webhipster.com/testing/accessibility/birthday/index.html
<form role="form" action="">
<div>
<label id="birthday" for="month">Birthday</label>
</div>
<div>
<input id="month" type="number" name="day" size="2"
aria-labelledby="birthday mm" />
<label id="mm" for="month"><abbr title="Two Digit
Month">MM</abbr></label>
</div>
<div> / </div>
<div>
<input id="day" type="number" name="day" size="2"
aria-labelledby="birthday dd" />
<label id="dd" for="day"><abbr title="Two Digit
Day">DD</abbr></label>
</div>
<div> / </div>
<div>
<input id="year" type="number" name="year" size="4"
aria-labelledby="birthday yyyy" />
<label id="yyyy" for="year"><abbr title="Four Digit
Year">YYYY</abbr></label>
</div>
</form>
If any interest, happy to discuss.
On Tue, Nov 8, 2011 at 1:53 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >wrote:
> Hi Jared,
>
> you wrote:
>
> >There's nothing in HTML or accessibility specifications that tell AT
> >to use the title attribute as a label replacement.
>
> Besides what James has pointed out (ARIA implementation guide), it should
> be noted that there is no specification that tells user agents how many
> HTML features should be mapped and/or interpreted by the accessibility
> layer, thats what the HTML to Platform Accessibility APIs Implementation
> Guide
> http://dev.w3.org/html5/html-api-map/overview.html is starting to
> document.
> Note in the section titled accessible name and description calculation (
> http://dev.w3.org/html5/html-api-map/overview.html#calc) the title
> attribute is included in accessible name calculation. The main reason for
> this is that every browser maps the title attribute to the accessible name
> property in every accessibility API and have done so for many versions ( i
> would suggest for as long as they have had accessibility support).
>
> For AT that use information exposed via an accessibility API, it is the
> accessible name property they use regardless of whether the source of the
> name is from the label element, aria attribute, element content or title
> attribute.
>
> regards
> Stevef
>
>
>
>
>
>
> On 8 November 2011 15:56, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> > I have several concerns over the use of the title attribute value for
> > labeling controls:
> >
> > - It shouldn't be used if a visible text label is present on the page.
> > <label> should be used instead - it works in old browsers, and also
> > provides enhanced mouse accessibility, primarily for users with motor
> > disabilities.
> >
> > - As defined in the HTML spec, title attribute is for "advisory
> > information". If a form field is inaccessible without the title
> > attribute value, this sure sounds like more than "advisory
> > information".
> >
> > - There's nothing in HTML or accessibility specifications that tell AT
> > to use the title attribute as a label replacement. They just happen to
> > do this on their own. This behavior is really no different than IE
> > showing alt text in tooltips which everyone railed against as being a
> > violation of the spec. It makes me uncomfortable relying on the
> > non-standard quirks of screen readers for accessibility. As has been
> > noted, different screen readers treat the presentation of title
> > differently - and understandably so because a standard behavior is not
> > documented anywhere because the attribute is not even intended to work
> > this way.
> >
> >
> > With all of this said, it works relatively well. It just makes me
> > squirm a little bit. I tend to use off-screen <label> to ensure
> > accessibility in these situations.
> >
> > Jared
> >
From: John Foliot
Date: Tue, Nov 08 2011 4:06PM
Subject: Re: "Evil" code (was using title attribute as form field label)
← Previous message | Next message →
Sailesh Panchang wrote:
>
> Hello John,
> John:In my example, the aria-describedby concatenates both the first
> value (Birthday) and the second bit of string text (year as a 4 digit
> value), so that the appropriate behavior of a
> screen reader should be: "Birthday year as a 4 digit value". I ask you,
> which is the better user-experience?
>
> Sailesh: The aria-label text 'year as a 4 digit value' is only
> available to users whose AT supports the attribute.
> Not to everyone.
I have acknowledged this point 3 times now Sailesh. However, where does
this problem really lie? With the author who is using valid code to
mark-up complex data structures? With the mainstream browsers that are
reporting this aria markup to the Accessibility APIs on the various
operating systems? Or with the behind the curve Adaptive Technologies that
are letting their users down?
I want web accessibility so badly it hurts some days, and I don't think I
need to defend that point too hard on this list. But at the same time,
moving forward on the web is a social contract between content creator and
content consumer, and the consumer has a responsibility to stay caught up
with technology as well. Yes, yes, I know all the stats and anecdotal
evidence about the cost of upgrading and all, but I am also aware via the
WebAIM surveys that the update curve is actually shorter than many might
think. There reaches a point (and I think we are very close to it now)
where we say that to fully participate you need to have current tools:
that as web developers we will no longer support IE6 or Netscape 4.7 (or
their equivalent in the AT world).
> Sure this is better, then why not make it available to all? ... as
> regular visible text that can be made a label for instance.
In my code example, it is visible, as DD MM YYYY, with those 'letters'
directly below the input boxes. You still cannot properly label those
inputs in a meaningful way using the <label> element alone, in part
because the label element announces the contained text as the accessible
name, which means DD MM YYYY. We can and should do better than that.
As well, like it or not, there will be design considerations that require
that there *not* be text visible on the screen, and rather than arguing
whether that is right or wrong, we should instead focus on how to solve
that problem, rather than fighting the battle that "all text must be
visible", because we will lose that battle 9 times out of 10, like it or
not. You want practical results? That is not a practical results stance.
> At the minimum, the AT-user should at least get the on-screen text
> that is available to everyone and that text should be programatically
> determined. Can't help if it is "YYYY".
At a minimum, that is what my code sample delivers to tools that consume
ARIA. Beyond minimum, it actually delivers a better end user-experience
(with a more natural-language accessible name). Unless you are suggesting
that we only do the minimum to satisfy the legal requirements? Is that
what you are saying, that doing the minimum is enough?
>
> I am called upon to test / certify and people want to do the minimum
> and ask ' will this pass'?
> So I am concerned with what the standards / guidelines / SC say and
> indeed need to check them off one by one.
Sailesh, the guideline says that your content must be Perceivable,
Operable, Understandable and Robust - nothing more, nothing less. It does
not mandate how that must be done, nor does it suggest that your code
should somehow do hand-stands and double-loop twists to accommodate the
vagaries, existing bugs and legacy non-support of any specific tool or
combination of tools. The fact that these are real concerns that effect
real users is not lost on me, but using hacks to work around bugs is a
dangerous path that should only be undertaken as a final effort. Code to
the standards first, and then apply the patches. I will code to the
standard, and not to each and every combination of AT and browser I can
assemble in a lab.
> And I do have to consider what today's user agents (browsers and AT)
> do. I am all for innovation but the Web page should work here and now
> and allow users to perform the task they set out to do efficiently.
See above.
>
> John: This doesn't work: you can only do a direct 1-to-1 association
> with label:...
> Sailesh: That's not true. More than label can point to one form
> control.
Such as?...
> The 'for' of the labels will point to one 'id' of a form
> control.
> And this works fine with FF (with JAWS and NVDA) and has been like
> this for a while. Alas but does not work with IE 7/8/9.
Wait, first you argue that my solution doesn't work in some combinations
of browsers and AT, then you put forth an alternative solution that
doesn't work in some combinations of browsers and AT? How is this any
better?
> So I suggested make 'Birthday' and 'DD' as labels for the INPUT for
> 2-digit date.
> The label 'Birthday' will convey context and many users will be ok
> with it being read once.
Oh, so now you are suggesting that it will be OK for "many" users, but for
those users who it is not OK with, what then? You are advocating for a
solution today that is less than perfect as well: it too has mixed support
across browsers and AT, and it has the additional problem of introducing
potential cognitive problems to those users who are unsure what a text
input of YYYY is for, as they somehow miss the association that this is
the fact that it is the year of the birthday. Sorry Sailesh, I don't buy
it, certainly not as a best practices. This might be a hacked up solution
that sort of works today, but I will not accept that it is an acceptable
solution: we can and should do better.
> This is akin to what screen reader users experience when reading
> fieldset/legend or colspan cells with TH.
Except in those 2 examples, they meet the programmatically-associated
test, whereas in your example you are relying on "context" and implied
association with no programmatically determined code. *THAT* my friend
comes closer to "failing" SC 4.1.2.", which explicitly requires: "... the
name and role can be programmatically determined" - which means that the
only association would be YYYY, with Birthday being inferred but not set
programmatically.
>
> I'd like to talk if you wish (703-225-0380 ext 105)
We can take this off-line if you wish, but I think that this "public
airing" benefits the larger community, and so we should continue here.
Sailesh, I am not attacking you (just in case that is not clear), but
rather the "conventional wisdom" stance you seem to be advocating. I have
an expression (well, actually, I have lots of them), but this one states:
"Good enough rarely is (good, or enough)".
JF
From: Jared Smith
Date: Tue, Nov 08 2011 4:12PM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
On Tue, Nov 8, 2011 at 2:53 PM, Steve Faulkner wrote:
> For AT that use information exposed via an accessibility API, it is the
> accessible name property they use regardless of whether the source of the
> name is from the label element, aria attribute, element content or title
> attribute.
I understand. Despite what ARIA says or what accessibility APIs do,
this does not change the definition of the title attribute in the HTML
specification. If we want to redefine title to allow it to be an
alternative for form labeling (or description for frames for that
matter), this should occur in the spec, shouldn't it? You have to have
a very liberal and creative interpretation of the HTML spec to
interpret "advisory information" to mean "accessible name".
Jared
From: Kevin Chao
Date: Tue, Nov 08 2011 10:03PM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
Hi Vincent,
This is working great with Firefox 10 Nightly and NVDA 2012.1 Snapshot in that:
navigating through form fields with TAB, E, or F; NVDA is reading
"Birthday, (MM, DD, or YYYY), edit has auto complete"
However, from the top, using DOWN ARROW to navigate through the form:
Birthday
Edit has Autocomplete
MM
The label "MM" should come before "edit has autocomplete"
Kevin
On 11/8/11, Vincent Young < = EMAIL ADDRESS REMOVED = > wrote:
> John your implementation is pretty sexy. Lots of different ways to go
> about this. I had some fun with it and came up with my own implementation:
>
> http://webhipster.com/testing/accessibility/birthday/index.html
>
> <form role="form" action="">
> <div>
> <label id="birthday" for="month">Birthday</label>
> </div>
> <div>
> <input id="month" type="number" name="day" size="2"
> aria-labelledby="birthday mm" />
> <label id="mm" for="month"><abbr title="Two Digit
> Month">MM</abbr></label>
> </div>
> <div> / </div>
> <div>
> <input id="day" type="number" name="day" size="2"
> aria-labelledby="birthday dd" />
> <label id="dd" for="day"><abbr title="Two Digit
> Day">DD</abbr></label>
> </div>
> <div> / </div>
> <div>
> <input id="year" type="number" name="year" size="4"
> aria-labelledby="birthday yyyy" />
> <label id="yyyy" for="year"><abbr title="Four Digit
> Year">YYYY</abbr></label>
> </div>
> </form>
>
> If any interest, happy to discuss.
>
> On Tue, Nov 8, 2011 at 1:53 PM, Steve Faulkner
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Hi Jared,
>>
>> you wrote:
>>
>> >There's nothing in HTML or accessibility specifications that tell AT
>> >to use the title attribute as a label replacement.
>>
>> Besides what James has pointed out (ARIA implementation guide), it should
>> be noted that there is no specification that tells user agents how many
>> HTML features should be mapped and/or interpreted by the accessibility
>> layer, thats what the HTML to Platform Accessibility APIs Implementation
>> Guide
>> http://dev.w3.org/html5/html-api-map/overview.html is starting to
>> document.
>> Note in the section titled accessible name and description calculation (
>> http://dev.w3.org/html5/html-api-map/overview.html#calc) the title
>> attribute is included in accessible name calculation. The main reason for
>> this is that every browser maps the title attribute to the accessible name
>> property in every accessibility API and have done so for many versions ( i
>> would suggest for as long as they have had accessibility support).
>>
>> For AT that use information exposed via an accessibility API, it is the
>> accessible name property they use regardless of whether the source of the
>> name is from the label element, aria attribute, element content or title
>> attribute.
>>
>> regards
>> Stevef
>>
>>
>>
>>
>>
>>
>> On 8 November 2011 15:56, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > I have several concerns over the use of the title attribute value for
>> > labeling controls:
>> >
>> > - It shouldn't be used if a visible text label is present on the page.
>> > <label> should be used instead - it works in old browsers, and also
>> > provides enhanced mouse accessibility, primarily for users with motor
>> > disabilities.
>> >
>> > - As defined in the HTML spec, title attribute is for "advisory
>> > information". If a form field is inaccessible without the title
>> > attribute value, this sure sounds like more than "advisory
>> > information".
>> >
>> > - There's nothing in HTML or accessibility specifications that tell AT
>> > to use the title attribute as a label replacement. They just happen to
>> > do this on their own. This behavior is really no different than IE
>> > showing alt text in tooltips which everyone railed against as being a
>> > violation of the spec. It makes me uncomfortable relying on the
>> > non-standard quirks of screen readers for accessibility. As has been
>> > noted, different screen readers treat the presentation of title
>> > differently - and understandably so because a standard behavior is not
>> > documented anywhere because the attribute is not even intended to work
>> > this way.
>> >
>> >
>> > With all of this said, it works relatively well. It just makes me
>> > squirm a little bit. I tend to use off-screen <label> to ensure
>> > accessibility in these situations.
>> >
>> > Jared
>> >
From: Vincent Young
Date: Wed, Nov 09 2011 12:00AM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
Kevin I would typically design my form so the label appears before the form
field visually and in HTML. John's example has the label appearing after
the form field (if I remember correctly) so I stuck to the design. Edited
and put the labels first, but after taking a second look, reworked it. The
date parts are in an unordered list and the forward slash is inserted with
the "content" CSS style declaration (could've also done a background
image). I think this example is my favorite.
http://webhipster.com/testing/accessibility/birthday/index.html
Mmmmm... clean.
On Tue, Nov 8, 2011 at 9:03 PM, Kevin Chao < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Vincent,
>
> This is working great with Firefox 10 Nightly and NVDA 2012.1 Snapshot in
> that:
> navigating through form fields with TAB, E, or F; NVDA is reading
> "Birthday, (MM, DD, or YYYY), edit has auto complete"
>
> However, from the top, using DOWN ARROW to navigate through the form:
> Birthday
> Edit has Autocomplete
> MM
>
> The label "MM" should come before "edit has autocomplete"
>
> Kevin
>
> On 11/8/11, Vincent Young < = EMAIL ADDRESS REMOVED = > wrote:
> > John your implementation is pretty sexy. Lots of different ways to go
> > about this. I had some fun with it and came up with my own
> implementation:
> >
> > http://webhipster.com/testing/accessibility/birthday/index.html
> >
> > <form role="form" action="">
> > <div>
> > <label id="birthday" for="month">Birthday</label>
> > </div>
> > <div>
> > <input id="month" type="number" name="day" size="2"
> > aria-labelledby="birthday mm" />
> > <label id="mm" for="month"><abbr title="Two Digit
> > Month">MM</abbr></label>
> > </div>
> > <div> / </div>
> > <div>
> > <input id="day" type="number" name="day" size="2"
> > aria-labelledby="birthday dd" />
> > <label id="dd" for="day"><abbr title="Two Digit
> > Day">DD</abbr></label>
> > </div>
> > <div> / </div>
> > <div>
> > <input id="year" type="number" name="year" size="4"
> > aria-labelledby="birthday yyyy" />
> > <label id="yyyy" for="year"><abbr title="Four Digit
> > Year">YYYY</abbr></label>
> > </div>
> > </form>
> >
> > If any interest, happy to discuss.
> >
> > On Tue, Nov 8, 2011 at 1:53 PM, Steve Faulkner
> > < = EMAIL ADDRESS REMOVED = >wrote:
> >
> >> Hi Jared,
> >>
> >> you wrote:
> >>
> >> >There's nothing in HTML or accessibility specifications that tell AT
> >> >to use the title attribute as a label replacement.
> >>
> >> Besides what James has pointed out (ARIA implementation guide), it
> should
> >> be noted that there is no specification that tells user agents how many
> >> HTML features should be mapped and/or interpreted by the accessibility
> >> layer, thats what the HTML to Platform Accessibility APIs Implementation
> >> Guide
> >> http://dev.w3.org/html5/html-api-map/overview.html is starting to
> >> document.
> >> Note in the section titled accessible name and description calculation (
> >> http://dev.w3.org/html5/html-api-map/overview.html#calc) the title
> >> attribute is included in accessible name calculation. The main reason
> for
> >> this is that every browser maps the title attribute to the accessible
> name
> >> property in every accessibility API and have done so for many versions
> ( i
> >> would suggest for as long as they have had accessibility support).
> >>
> >> For AT that use information exposed via an accessibility API, it is the
> >> accessible name property they use regardless of whether the source of
> the
> >> name is from the label element, aria attribute, element content or title
> >> attribute.
> >>
> >> regards
> >> Stevef
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 8 November 2011 15:56, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> >>
> >> > I have several concerns over the use of the title attribute value for
> >> > labeling controls:
> >> >
> >> > - It shouldn't be used if a visible text label is present on the page.
> >> > <label> should be used instead - it works in old browsers, and also
> >> > provides enhanced mouse accessibility, primarily for users with motor
> >> > disabilities.
> >> >
> >> > - As defined in the HTML spec, title attribute is for "advisory
> >> > information". If a form field is inaccessible without the title
> >> > attribute value, this sure sounds like more than "advisory
> >> > information".
> >> >
> >> > - There's nothing in HTML or accessibility specifications that tell AT
> >> > to use the title attribute as a label replacement. They just happen to
> >> > do this on their own. This behavior is really no different than IE
> >> > showing alt text in tooltips which everyone railed against as being a
> >> > violation of the spec. It makes me uncomfortable relying on the
> >> > non-standard quirks of screen readers for accessibility. As has been
> >> > noted, different screen readers treat the presentation of title
> >> > differently - and understandably so because a standard behavior is not
> >> > documented anywhere because the attribute is not even intended to work
> >> > this way.
> >> >
> >> >
> >> > With all of this said, it works relatively well. It just makes me
> >> > squirm a little bit. I tend to use off-screen <label> to ensure
> >> > accessibility in these situations.
> >> >
> >> > Jared
> >> >
From: Kevin Chao
Date: Wed, Nov 09 2011 12:15AM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
Vincent,
Excellent job! Thanks! Works great on iPhone, iOS 5, Safari, and VoiceOver. It's great when swiping left/right to go to previous/next element, using web rotor>form field (SWIPING UP/DOWN for previous/next form field) and Apple wireless keyboard to TAB and SHIFT-TAB among form fields.
Label is read before edit box. When focused on form field, birthday, label, and edit box is spoken. VoiceOver properly sees the three edit boxes as being in an unordered list.
Sent from my iPhone
On Nov 9, 2011, at 1:02 AM, Vincent Young < = EMAIL ADDRESS REMOVED = > wrote:
> Kevin I would typically design my form so the label appears before the form
> field visually and in HTML. John's example has the label appearing after
> the form field (if I remember correctly) so I stuck to the design. Edited
> and put the labels first, but after taking a second look, reworked it. The
> date parts are in an unordered list and the forward slash is inserted with
> the "content" CSS style declaration (could've also done a background
> image). I think this example is my favorite.
>
> http://webhipster.com/testing/accessibility/birthday/index.html
>
> Mmmmm... clean.
>
>
>
>
>
> On Tue, Nov 8, 2011 at 9:03 PM, Kevin Chao < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi Vincent,
>>
>> This is working great with Firefox 10 Nightly and NVDA 2012.1 Snapshot in
>> that:
>> navigating through form fields with TAB, E, or F; NVDA is reading
>> "Birthday, (MM, DD, or YYYY), edit has auto complete"
>>
>> However, from the top, using DOWN ARROW to navigate through the form:
>> Birthday
>> Edit has Autocomplete
>> MM
>>
>> The label "MM" should come before "edit has autocomplete"
>>
>> Kevin
>>
>> On 11/8/11, Vincent Young < = EMAIL ADDRESS REMOVED = > wrote:
>>> John your implementation is pretty sexy. Lots of different ways to go
>>> about this. I had some fun with it and came up with my own
>> implementation:
>>>
>>> http://webhipster.com/testing/accessibility/birthday/index.html
>>>
>>> <form role="form" action="">
>>> <div>
>>> <label id="birthday" for="month">Birthday</label>
>>> </div>
>>> <div>
>>> <input id="month" type="number" name="day" size="2"
>>> aria-labelledby="birthday mm" />
>>> <label id="mm" for="month"><abbr title="Two Digit
>>> Month">MM</abbr></label>
>>> </div>
>>> <div> / </div>
>>> <div>
>>> <input id="day" type="number" name="day" size="2"
>>> aria-labelledby="birthday dd" />
>>> <label id="dd" for="day"><abbr title="Two Digit
>>> Day">DD</abbr></label>
>>> </div>
>>> <div> / </div>
>>> <div>
>>> <input id="year" type="number" name="year" size="4"
>>> aria-labelledby="birthday yyyy" />
>>> <label id="yyyy" for="year"><abbr title="Four Digit
>>> Year">YYYY</abbr></label>
>>> </div>
>>> </form>
>>>
>>> If any interest, happy to discuss.
>>>
>>> On Tue, Nov 8, 2011 at 1:53 PM, Steve Faulkner
>>> < = EMAIL ADDRESS REMOVED = >wrote:
>>>
>>>> Hi Jared,
>>>>
>>>> you wrote:
>>>>
>>>>> There's nothing in HTML or accessibility specifications that tell AT
>>>>> to use the title attribute as a label replacement.
>>>>
>>>> Besides what James has pointed out (ARIA implementation guide), it
>> should
>>>> be noted that there is no specification that tells user agents how many
>>>> HTML features should be mapped and/or interpreted by the accessibility
>>>> layer, thats what the HTML to Platform Accessibility APIs Implementation
>>>> Guide
>>>> http://dev.w3.org/html5/html-api-map/overview.html is starting to
>>>> document.
>>>> Note in the section titled accessible name and description calculation (
>>>> http://dev.w3.org/html5/html-api-map/overview.html#calc) the title
>>>> attribute is included in accessible name calculation. The main reason
>> for
>>>> this is that every browser maps the title attribute to the accessible
>> name
>>>> property in every accessibility API and have done so for many versions
>> ( i
>>>> would suggest for as long as they have had accessibility support).
>>>>
>>>> For AT that use information exposed via an accessibility API, it is the
>>>> accessible name property they use regardless of whether the source of
>> the
>>>> name is from the label element, aria attribute, element content or title
>>>> attribute.
>>>>
>>>> regards
>>>> Stevef
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 8 November 2011 15:56, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>>>>
>>>>> I have several concerns over the use of the title attribute value for
>>>>> labeling controls:
>>>>>
>>>>> - It shouldn't be used if a visible text label is present on the page.
>>>>> <label> should be used instead - it works in old browsers, and also
>>>>> provides enhanced mouse accessibility, primarily for users with motor
>>>>> disabilities.
>>>>>
>>>>> - As defined in the HTML spec, title attribute is for "advisory
>>>>> information". If a form field is inaccessible without the title
>>>>> attribute value, this sure sounds like more than "advisory
>>>>> information".
>>>>>
>>>>> - There's nothing in HTML or accessibility specifications that tell AT
>>>>> to use the title attribute as a label replacement. They just happen to
>>>>> do this on their own. This behavior is really no different than IE
>>>>> showing alt text in tooltips which everyone railed against as being a
>>>>> violation of the spec. It makes me uncomfortable relying on the
>>>>> non-standard quirks of screen readers for accessibility. As has been
>>>>> noted, different screen readers treat the presentation of title
>>>>> differently - and understandably so because a standard behavior is not
>>>>> documented anywhere because the attribute is not even intended to work
>>>>> this way.
>>>>>
>>>>>
>>>>> With all of this said, it works relatively well. It just makes me
>>>>> squirm a little bit. I tend to use off-screen <label> to ensure
>>>>> accessibility in these situations.
>>>>>
>>>>> Jared
>>>>>
From: Vincent Young
Date: Wed, Nov 09 2011 2:54AM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
Cool. Question for you or anyone else with interest: using the input type
= number on IOS the number keypad comes up which makes things convenient.
However, currently the number type does not respect the maxlength
attribute. Maxlength is nice on IOS because when you have reached the
maxlength and tap on a character, nothing is voiced, signaling you've
reached the max. From a usability standpoint what do you find more...
usable. The prevention of typing in too many characters or the number
keypad appearing?
On Tue, Nov 8, 2011 at 11:12 PM, Kevin Chao < = EMAIL ADDRESS REMOVED = > wrote:
> Vincent,
> Excellent job! Thanks! Works great on iPhone, iOS 5, Safari, and
> VoiceOver. It's great when swiping left/right to go to previous/next
> element, using web rotor>form field (SWIPING UP/DOWN for previous/next form
> field) and Apple wireless keyboard to TAB and SHIFT-TAB among form fields.
>
> Label is read before edit box. When focused on form field, birthday,
> label, and edit box is spoken. VoiceOver properly sees the three edit boxes
> as being in an unordered list.
>
> Sent from my iPhone
>
> On Nov 9, 2011, at 1:02 AM, Vincent Young < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Kevin I would typically design my form so the label appears before the
> form
> > field visually and in HTML. John's example has the label appearing after
> > the form field (if I remember correctly) so I stuck to the design.
> Edited
> > and put the labels first, but after taking a second look, reworked it.
> The
> > date parts are in an unordered list and the forward slash is inserted
> with
> > the "content" CSS style declaration (could've also done a background
> > image). I think this example is my favorite.
> >
> > http://webhipster.com/testing/accessibility/birthday/index.html
> >
> > Mmmmm... clean.
> >
> >
> >
> >
> >
> > On Tue, Nov 8, 2011 at 9:03 PM, Kevin Chao < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> Hi Vincent,
> >>
> >> This is working great with Firefox 10 Nightly and NVDA 2012.1 Snapshot
> in
> >> that:
> >> navigating through form fields with TAB, E, or F; NVDA is reading
> >> "Birthday, (MM, DD, or YYYY), edit has auto complete"
> >>
> >> However, from the top, using DOWN ARROW to navigate through the form:
> >> Birthday
> >> Edit has Autocomplete
> >> MM
> >>
> >> The label "MM" should come before "edit has autocomplete"
> >>
> >> Kevin
> >>
> >> On 11/8/11, Vincent Young < = EMAIL ADDRESS REMOVED = > wrote:
> >>> John your implementation is pretty sexy. Lots of different ways to go
> >>> about this. I had some fun with it and came up with my own
> >> implementation:
> >>>
> >>> http://webhipster.com/testing/accessibility/birthday/index.html
> >>>
> >>> <form role="form" action="">
> >>> <div>
> >>> <label id="birthday" for="month">Birthday</label>
> >>> </div>
> >>> <div>
> >>> <input id="month" type="number" name="day" size="2"
> >>> aria-labelledby="birthday mm" />
> >>> <label id="mm" for="month"><abbr title="Two Digit
> >>> Month">MM</abbr></label>
> >>> </div>
> >>> <div> / </div>
> >>> <div>
> >>> <input id="day" type="number" name="day" size="2"
> >>> aria-labelledby="birthday dd" />
> >>> <label id="dd" for="day"><abbr title="Two Digit
> >>> Day">DD</abbr></label>
> >>> </div>
> >>> <div> / </div>
> >>> <div>
> >>> <input id="year" type="number" name="year" size="4"
> >>> aria-labelledby="birthday yyyy" />
> >>> <label id="yyyy" for="year"><abbr title="Four Digit
> >>> Year">YYYY</abbr></label>
> >>> </div>
> >>> </form>
> >>>
> >>> If any interest, happy to discuss.
> >>>
> >>> On Tue, Nov 8, 2011 at 1:53 PM, Steve Faulkner
> >>> < = EMAIL ADDRESS REMOVED = >wrote:
> >>>
> >>>> Hi Jared,
> >>>>
> >>>> you wrote:
> >>>>
> >>>>> There's nothing in HTML or accessibility specifications that tell AT
> >>>>> to use the title attribute as a label replacement.
> >>>>
> >>>> Besides what James has pointed out (ARIA implementation guide), it
> >> should
> >>>> be noted that there is no specification that tells user agents how
> many
> >>>> HTML features should be mapped and/or interpreted by the accessibility
> >>>> layer, thats what the HTML to Platform Accessibility APIs
> Implementation
> >>>> Guide
> >>>> http://dev.w3.org/html5/html-api-map/overview.html is starting to
> >>>> document.
> >>>> Note in the section titled accessible name and description
> calculation (
> >>>> http://dev.w3.org/html5/html-api-map/overview.html#calc) the title
> >>>> attribute is included in accessible name calculation. The main reason
> >> for
> >>>> this is that every browser maps the title attribute to the accessible
> >> name
> >>>> property in every accessibility API and have done so for many versions
> >> ( i
> >>>> would suggest for as long as they have had accessibility support).
> >>>>
> >>>> For AT that use information exposed via an accessibility API, it is
> the
> >>>> accessible name property they use regardless of whether the source of
> >> the
> >>>> name is from the label element, aria attribute, element content or
> title
> >>>> attribute.
> >>>>
> >>>> regards
> >>>> Stevef
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 8 November 2011 15:56, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> >>>>
> >>>>> I have several concerns over the use of the title attribute value for
> >>>>> labeling controls:
> >>>>>
> >>>>> - It shouldn't be used if a visible text label is present on the
> page.
> >>>>> <label> should be used instead - it works in old browsers, and also
> >>>>> provides enhanced mouse accessibility, primarily for users with motor
> >>>>> disabilities.
> >>>>>
> >>>>> - As defined in the HTML spec, title attribute is for "advisory
> >>>>> information". If a form field is inaccessible without the title
> >>>>> attribute value, this sure sounds like more than "advisory
> >>>>> information".
> >>>>>
> >>>>> - There's nothing in HTML or accessibility specifications that tell
> AT
> >>>>> to use the title attribute as a label replacement. They just happen
> to
> >>>>> do this on their own. This behavior is really no different than IE
> >>>>> showing alt text in tooltips which everyone railed against as being a
> >>>>> violation of the spec. It makes me uncomfortable relying on the
> >>>>> non-standard quirks of screen readers for accessibility. As has been
> >>>>> noted, different screen readers treat the presentation of title
> >>>>> differently - and understandably so because a standard behavior is
> not
> >>>>> documented anywhere because the attribute is not even intended to
> work
> >>>>> this way.
> >>>>>
> >>>>>
> >>>>> With all of this said, it works relatively well. It just makes me
> >>>>> squirm a little bit. I tend to use off-screen <label> to ensure
> >>>>> accessibility in these situations.
> >>>>>
> >>>>> Jared
> >>>>>
From: Steve Faulkner
Date: Wed, Nov 09 2011 9:42AM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
Hi Jared, have posted a bug against the HTML5 spec about this
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14740
regards
steve
On 8 November 2011 23:05, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Tue, Nov 8, 2011 at 2:53 PM, Steve Faulkner wrote:
>
> > For AT that use information exposed via an accessibility API, it is the
> > accessible name property they use regardless of whether the source of the
> > name is from the label element, aria attribute, element content or title
> > attribute.
>
> I understand. Despite what ARIA says or what accessibility APIs do,
> this does not change the definition of the title attribute in the HTML
> specification. If we want to redefine title to allow it to be an
> alternative for form labeling (or description for frames for that
> matter), this should occur in the spec, shouldn't it? You have to have
> a very liberal and creative interpretation of the HTML spec to
> interpret "advisory information" to mean "accessible name".
>
> Jared
>
From: Vincent Young
Date: Wed, Nov 09 2011 4:30PM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
Bump. Any opinions on the below:
Using the input type = number on IOS the number keypad comes up but
maxlength is not honored. For now what is more important, having the
proper keypad come up or keeping the user from entering too many
characters? This seems like a real usability/accessibility issue but maybe
not. If anyone has suggestions about how to get both to work for the date
example John presented please share.
On Wed, Nov 9, 2011 at 8:41 AM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >wrote:
> Hi Jared, have posted a bug against the HTML5 spec about this
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14740
>
> regards
> steve
>
> On 8 November 2011 23:05, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> > On Tue, Nov 8, 2011 at 2:53 PM, Steve Faulkner wrote:
> >
> > > For AT that use information exposed via an accessibility API, it is the
> > > accessible name property they use regardless of whether the source of
> the
> > > name is from the label element, aria attribute, element content or
> title
> > > attribute.
> >
> > I understand. Despite what ARIA says or what accessibility APIs do,
> > this does not change the definition of the title attribute in the HTML
> > specification. If we want to redefine title to allow it to be an
> > alternative for form labeling (or description for frames for that
> > matter), this should occur in the spec, shouldn't it? You have to have
> > a very liberal and creative interpretation of the HTML spec to
> > interpret "advisory information" to mean "accessible name".
> >
> > Jared
> >
From: Bryan Garaventa
Date: Wed, Nov 09 2011 4:42PM
Subject: Re: using title attribute as form field label
← Previous message | Next message →
If maxlength isn't honored, you could check the number of chars using a
handler then pass or fail acordingly, then you would have both. This might
do it.
----- Original Message -----
From: "Vincent Young" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, November 09, 2011 3:27 PM
Subject: Re: [WebAIM] using title attribute as form field label
> Bump. Any opinions on the below:
>
> Using the input type = number on IOS the number keypad comes up but
> maxlength is not honored. For now what is more important, having the
> proper keypad come up or keeping the user from entering too many
> characters? This seems like a real usability/accessibility issue but
> maybe
> not. If anyone has suggestions about how to get both to work for the date
> example John presented please share.
>
> On Wed, Nov 9, 2011 at 8:41 AM, Steve Faulkner
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Hi Jared, have posted a bug against the HTML5 spec about this
>>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14740
>>
>> regards
>> steve
>>
>> On 8 November 2011 23:05, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > On Tue, Nov 8, 2011 at 2:53 PM, Steve Faulkner wrote:
>> >
>> > > For AT that use information exposed via an accessibility API, it is
>> > > the
>> > > accessible name property they use regardless of whether the source of
>> the
>> > > name is from the label element, aria attribute, element content or
>> title
>> > > attribute.
>> >
>> > I understand. Despite what ARIA says or what accessibility APIs do,
>> > this does not change the definition of the title attribute in the HTML
>> > specification. If we want to redefine title to allow it to be an
>> > alternative for form labeling (or description for frames for that
>> > matter), this should occur in the spec, shouldn't it? You have to have
>> > a very liberal and creative interpretation of the HTML spec to
>> > interpret "advisory information" to mean "accessible name".
>> >
>> > Jared
>> >
From: Kevin Chao
Date: Wed, Nov 09 2011 4:54PM
Subject: Re: using title attribute as form field label
← Previous message | No next message
Having proper iOS virtual on-screen keypad come up is much more
important from an accessibility and usability point, which would be
followed by preventing too many characters from being entered.
Kevin
On 11/9/11, Vincent Young < = EMAIL ADDRESS REMOVED = > wrote:
> Bump. Any opinions on the below:
>
> Using the input type = number on IOS the number keypad comes up but
> maxlength is not honored. For now what is more important, having the
> proper keypad come up or keeping the user from entering too many
> characters? This seems like a real usability/accessibility issue but maybe
> not. If anyone has suggestions about how to get both to work for the date
> example John presented please share.
>
> On Wed, Nov 9, 2011 at 8:41 AM, Steve Faulkner
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Hi Jared, have posted a bug against the HTML5 spec about this
>>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14740
>>
>> regards
>> steve
>>
>> On 8 November 2011 23:05, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > On Tue, Nov 8, 2011 at 2:53 PM, Steve Faulkner wrote:
>> >
>> > > For AT that use information exposed via an accessibility API, it is
>> > > the
>> > > accessible name property they use regardless of whether the source of
>> the
>> > > name is from the label element, aria attribute, element content or
>> title
>> > > attribute.
>> >
>> > I understand. Despite what ARIA says or what accessibility APIs do,
>> > this does not change the definition of the title attribute in the HTML
>> > specification. If we want to redefine title to allow it to be an
>> > alternative for form labeling (or description for frames for that
>> > matter), this should occur in the spec, shouldn't it? You have to have
>> > a very liberal and creative interpretation of the HTML spec to
>> > interpret "advisory information" to mean "accessible name".
>> >
>> > Jared
>> >