WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: "Evil" code (was using title attribute as form field label)

for

From: Sailesh Panchang
Date: Nov 8, 2011 1:48PM

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 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
>
>
>
>