- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sun, 23 Sep 2012 10:25:11 +1000
- To: Charles McCathie Nevile <chaals@yandex-team.ru>
- Cc: David Singer <singer@apple.com>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
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