- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 25 Mar 2011 16:53:04 -0700
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: Henri Sivonen <hsivonen@iki.fi>, HTMLWG WG <public-html@w3.org>
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