WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: John Foliot
Date: Nov 8, 2011 10:03AM

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