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 4:06PM

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