On 8/24/11 10:41 PM, Jukka K. Korpela wrote:
> 24.8.2011 23:50, Clint Goss wrote:
>
>> ARIA does seem to be a comprehensive proposal for accessibility.
>
> It is specifically about accessibility (not about the idea of
> providing alternative presentations in general), it is complex, it is
> meant for specialized user agents and assistive software (as opposite
> to mainstream browsers in normal use, the use that most authors and
> developers focus on), and it is difficult to test.
I've found, as a developer, that ARIA has strong use cases outside of
accessibility; mainly, in UI development.
By storing additional state data in the DOM, I'm able to both -see- what
I'm doing, without needing to go into introspection in the script, and
I'm able to inter-operate with other scripts, speaking the same standard
language.
element.setAttribute('aria-pressed', true) has helped me on several
occasions. ARIA has a large vocabulary, and it certainly has a learning
curve, but like other standards; css3, html5, it's worth learning, and
it's a big help in development... it's also something that can be
learned piecemeal. I'm not so concerned about testing, in this case, as
I am with simply getting developers to start using it.
When ARIA is used with the scripting environment, testing just
"happens". If an attribute is mis-set, it becomes pretty obvious, as the
scripting environment relies on its proper setting to function. So if I
use ARIA, and I do not set my pressed attribute correctly, my site
breaks, quite noticeably.
>
> So I'm afraid it will be used by a small minority of authors and
> developers only.
We're in the same situation with alt: only a small minority of authors
and developers use it,
and the same with the title tag in SVG. Clint Goss' comments about
advocacy ["social engineering"] still apply.
Only a minority of devs/authors use the labels appropriately.
>> (although I was not able to quickly find
>> stats on compliance of the mandatory @alt).
>
> One might measure the compliance to the formal requirement of having
> an alt attribute for every <img>. But this would give much too high
> figures, since it is so common to have alt attributes that are useless
> or worse, failing to comply with the requirement that the attribute
> specify a textual replacement for the image.
There's an '07 study on user frustrations with the computer; I believe
it was a survey of 100 non-sighted users... Missing image alts were high
on the list, as were poorly labeled/named links. Both require additional
human intervention.
IE9 F12 Developer Tools includes some functions to help "test" for ALT
tags. One of the reasons, I believe, why alt are not so common, is that
they're just not emphasized in authoring tools, nor development tools.
This is something that can and should be worked on further.
There are certainly difficulties in requesting titles. Consider cases
when users are uploading to an online forum, or a site, like
Blackboard-- in those cases, it's fairly easy to make adding a title a
part of the process... but unfortunately, many software packages were
not designed with WCAG / ATAG in mind. Those are areas we can advocate
change in.
There is then, the more difficult case, where users are uploading
multiple images, and asking them to label each image immediately would
not desirable. In those cases, again, it makes good sense to allow the
user to update the titles later, and to grant them a tool to help them
see which images are not labeled.
The user does not need to be told it's "for accessibility", but they
should be prompted with enough information to caption the image
appropriately.
Consider that, when a user sees a "caption this image" option, they may
add some kind of subtitle which makes a pun, or otherwise adds to the
image. That's fun, and useful, but it's not so useful for non-sighted
users. And that's where, again, the software that is being used can be a
big help. It can and should allow the user to write in descriptive
captions, additive captions, short captions, and so forth. But, most
software was not designed from that premise.
All of those caption types could be worthwhile for a user to provide.
But the tool has to allow them that provision.
>
> But _many_ authors _often_ use alt attributes in a useful way, and
> this helps people. On similar grounds, it would be useful to have a
> simple way of specifying textual replacement for text. But the problem
> is how to define the markup and how to define the conditions for using
> the textual replacement.
>
> In some use cases, it would suffice to define as follows: an alt
> attribute on a <span> element or other phrase element indicates the
> text to be used in place of the element content, if the content cannot
> be presented as graphic characters; for example:
> <span alt="diameter">&#x2300;</span>
> or
> <span alt="ø">&#x2300;</span>
> (A browser would be expected to use the alt fallback if it cannot
> render the content as the diameter sign, probably due to lack of such
> character in available fonts. And maybe the idea could be extended to
> rendering content non-visually; in that case, only the former fallback
> would make sense.)
>
I think that font fallback is a different issue, widely handled by
Unicode related standards.
That said, using aria, instead of specifying new tags, would both work
with ATs that support ARIA, and it would work for the scripting
environment, which the author-developer can tweak to the contentment of
their use case and their users.
Wouldn't something like this work out?:
<span role="img" aria-label="diameter">&#x2300;</span>
May not be the best example, but it's certainly something I can pick up
with the scripting environment, and post-process, to get additional
compatibility out of legacy browsers.
-Charles