Re: example spec text for longdesc

On Fri, Mar 25, 2011 at 5:48 AM, Laura Carlson
<laura.lee.carlson@gmail.com> wrote:
> Hi Henri,
>
> - public-html-a11y per  Philip's request [1]
>
> Thank you, Henri for sharing your expertise. I appreciate at it very much,
>
>>> Henri, how difficult would it be for conformance checkers to inspect a
>>> longdesc URL and issue a warning if it suspects that the description
>>> resource is unlikely to contain a description of the image (i.e., if
>>> the URL is an empty string,
>>
>> Easy.
>>
>>> or points to the same URL as the src
>>> attribute,
>>
>> Easyish.
>>
>>> And
>>> how difficult would it be for conformance checkers to issue errors if
>>> the longdesc URL has certain file suffixes, such as .gif, .jpeg, .png
>>> etc.)?
>>
>> Easy though bogus as far as the theory of URLs go. (In theory, you
>> should deference the URL and check the content type, but that would make
>> conformance dependent on external resources, which is kinda
>> undesirable.)
>
> Do you think that it would be a good idea for the spec to have
> language for conformance checking tools to do such checks if longdesc
> is reinstated into HTML?
>
>> In any case, approaching longdesc from the point of view of ease of
>> conformance checker implementation is the wrong way to approach it.
>> Frankly, all this seems to presume that longdesc must axiomatically be
>> preserved and then rationalizations are sought to justify the
>> conclusion.
>>
>> The right way is to consider what problems users face and what are
>> appropriate ways to solve those problems--not to focus on the
>> preservation of something that has been labeled as an accessibility
>> feature.
>
> Use cases are at:
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Use_Cases
>
> What are appropriate way to solve the formal use cases?
> http://www.d.umn.edu/~lcarlson/research/ld.html#uc

I would love it if we could actually talk about it this way, so I'll
just take this invitation and run with it.

First of all it has always surprised me that the list of use cases
only list discusses adding accessibility information to images. Is
there a reason things like tables, SVG (and portions thereof), figures
and forms are left out? Technically, wouldn't you even want to be able
to have a long description for a part of a web page that contains a
fairly complicated piece of UI?

Also, ease of use seems to be missing from that page. This isn't
really a use case but rather a requirement. However since the page
seems to be lacking a section for requirements maybe it would be ok to
list under use cases.

Would it be ok for me to go add these requirements to the wiki?

Once you include these use cases and requirements it seems much less
that longdesc is a proper solution. It's only available on <img>ages
(this missing all other ways even for including images such as
<canvas> and <object>). It isn't very user friendly. Lots of people
seem to misunderstand it to include the actual describing text rather
than a link to it. Not only that, but since it is url based, rather
than id based, it encourages people to put the description in an
external resource, which more often than not is not what you want to
do.

It turns out that ARIA already have a attribute that almost fits the
bill, and this is aria-describedby. As is pointed out on the wiki
page, the problem is that the ARIA specification only allows exposing
text content to the user, rather than arbitrary content, such as
links.

This problem can be fixed though by changing the ARIA specification.
By changing ARIA to say that aria-describedby can point to arbitrary
content, rather than just refer to the textual contents of it, we
solve multiple problems in one go.

This would first of all allow aria-describedby to solve all the use
cases in the wiki, as well as the ones pointed out in this message. It
also seems to fulfill the ease of use requirement better as people so
far seems to put an id in aria-describedby rather than the actual
text.

Additionally, it improves aria-describedby which currently IMHO
suffers both from ease of use problems, as well as
internationalization problems. It is very unintuitive to me that
aria-describedby points to an element, which can contain arbitrary
semantics, but then discards these semantics and only uses the
elements textual content. Additionally, some locales, such as
japanese, commonly uses markup, for example ruby, to expose important
semantics. aria-describedby currently drops these which seems like a
problem.

And yes, I am aware that the wiki claims that aria-describedby has
other problems. I'll deal with those if we can agree that this aspect
of aria-describedby can be fixed.

So, if we really want to focus on creating the best possible technical
solution for helping AT users, rather than focusing on restoring any
and all accessibility feature for HTML4 at all cost, then I think
there clearly are better solutions than longdesc.

I'd also add that I don't actually see where the ARIA spec says that
aria-describedby only exposes the textual content of the linked to
elements. [1] certainly doesn't say anything to that extent. But I'm
sure I'm just missing it.

[1] http://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby

/ Jonas

Received on Friday, 25 March 2011 23:54:07 UTC