Re: longdesc quality statistics

On Sat, Sep 22, 2012 at 2:52 AM, Charles McCathie Nevile
<chaals@yandex-team.ru> wrote:
> On Fri, 21 Sep 2012 18:03:39 +0200, David Singer <singer@apple.com> wrote:
>> On Sep 21, 2012, at 7:03 , Charles McCathie Nevile <chaals@yandex-team.ru>
>> wrote:
>>> I note 15 years ago when I began working seriously in accessibility, the
>>> alt attribute was something people generally thought was unreasonable,
>>> couldn't be done, was almost always missing, and when it was present it
>>> was almost always done so badly as to be a waste of time. I would
>>> characterise the situation now as about 10 times as good - maybe a
>>> majority of people accept it as a good idea, it is often present, and in
>>> many cases it isn't useless (although I honestly doubt that good use of
>>> alt has become the statistical norm, the almost 2 decades since it was
>>> introduced have seen significant improvement).
>>
>>
>>
>> Is that perhaps because of ordinary browsers exposing it during hover, do
>> you think?
>
>
> Partially. When that used to happen it was certainly a cause of all sorts of
> rubbish being put into alt. But the improvements were not only related to
> getting rid of that behaviour, but also a general improvement in developers'
> understanding and knowledge.

That to me sounds like we should not actually try to come up with
attributes that serve two use cases: to add something for screenreader
users as well as for ordinary browser behaviour. It seems that that
encourges people to misuse the attribute for their own unrelated
purposes. Being very clear about the accessibility-only use case of
@alt seems to have helped it.

Couple that with the need to have a long description alternative for
more than just images, the introduction of @aria-describedat sounds
more and more attractive to me. The aria prefix clearly signifies
accessibility-only use.

===
Note that I have also recently spoken with Dominic Mazzoni about his
position towards @longdesc and I got permission from him to forward
his email:

I'm not convinced by arguments in favor of including longdesc in html5
as-is, but I'm supportive of an equivalent ARIA attribute to replace
it. If this were to be a (non-deprecated) html5 attribute and not an
aria attribute, I think it should be generally useful to web
developers for purposes other than accessibility. I'm not convinced by
the arguments here; I've seen no evidence that this is a feature
general web developers have been asking for, nor have I seen any
evidence they'd actually use it.

In cases where an image needs a long description that's useful to a
wide range of users, existing html5 and css is more than sufficient to
provide ways to add links or pop-ups with more information, in a way
that fits with an existing site design. Thousands of websites have
already solved this problem in different ways, and in fact it is the
variety of creative ways this problem can be solved that convinces me
that "longdesc" that provides just one solution is unlikely to be
useful to web developers.

 I do believe it would be useful to have an aria attribute that would
provide accessible semantic metadata about an existing long
description - such as an attribute that associates a link to more
information with the image it references.

If there was no history of longdesc and we started discussing the
problem it's trying to solve and its use cases, I think there's a good
chance there are other solutions we might be able to find. Perhaps
there is a need for a general-purpose html5 tag or attribute for long
descriptions. But the fact that longdesc is already in html4 means
that this is more of an all-or-nothing discussion. The fact that it's
been around for a long time, rarely used, and arguably used
incorrectly more than correctly is evidence to me that deprecation is
the right solution.

==

I also asked him that given the following alternatives, which would he pick:

1. Obsolete attribute
* expect aria-describedat to be defined for HTML.next (it's too late for HTML5)
* in the meantime for HTML5 have @longdesc be obsolete but conforming
with an expectation that in the long run aria-describedat will replace
it; this will raise a warning by validators

2. Non-conforming attribute
* expect aria-describedat to be defined for HTML.next (it's too late for HTML5)
* in the meantime for HTML5 have @longdesc be non-conforming and raise
an error by validators

3. Conforming attribute
* expect aria-describedat to be defined for HTML.next (it's too late for HTML5)
* retain @longdesc as a valid attribute but with an expectation that
it is only exposed in the context menu, while aria-describedat is
exposed in the a11y API

Dominic's choice was as follows:

I learn towards #2 since
longdesc has been around for so long and is rarely used correctly. I
just don't see much chance that any browser would implement it, so I
think it's more useful to make it a validation error. I also think
that making it an error would make it more likely we could point
people at aria-describedat.

Note that Dominic is a huge fan and supporter of accessibility and he
has the best at mind for many different accessibility uses. A visual
encumbrance for longdesc is just not something that browsers will
implement, because it restricts the Web developer/designer.

Dominic thus leans towards non-conformance, even if that creates a
vacuum until an aria attribute is released, and I can follow his
arguments.

Thus, we should likely put more effort behind making @aria-describedat
a full blown extension spec and start encouraging Web browsers and AT
to implement support for it rather than wasting more time on a
discussion that will not get us a single additional browser vendor to
implement support for.

Note that I personally would lean towards #1 above for HTML5, with an
expectation that it will be #2 above in HTML.next, thus providing a
deprecation path. It would, however, change nothing in the fact we
should as a task force get behind the @aria-describedat extension
spec, figure out the details, and lobby the browser vendors for
implementations. That's likely the most productive path forward.

Also a final word about the aria prefix on describedat. I would prefer
to keep it as an accessibility-only feature with a comment to Web
developers to encourage them to provide the long description not just
to AT through this attribute but to provide other appropriate means of
exposing the content of that linked description to sighted users as
well. This way the main target audience is clear and other target
audiences can be served, too, but don't have to. Since the target
audience is accessibility, the aria prefix makes sense, since Web
developers have got used to this prefix meaning "accessibility".

For this reason, I would also be happy to have WAI develop this
feature, but - as has been stated multiple times - PFWG is not
currently in a position to add new features to ARIA. So, an extension
specification developed here that can ultimately be picked up for ARIA
2 might be the quickest way forward here without stepping on processes
required by HTML or PF WGs.

Regards,
Silvia.

Received on Sunday, 23 September 2012 00:25:59 UTC