- From: John Foliot <jfoliot@stanford.edu>
- Date: Fri, 25 Mar 2011 19:21:27 -0700 (PDT)
- To: "'Jonas Sicking'" <jonas@sicking.cc>, "'Laura Carlson'" <laura.lee.carlson@gmail.com>
- Cc: "'Henri Sivonen'" <hsivonen@iki.fi>, "'HTMLWG WG'" <public-html@w3.org>
Jonas Sicking wrote: > > 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? Thanks for the good questions Jonas. I appreciate the fact that there is ongoing dialog about @longdesc as we collectively seek to make a better web for all. In actual fact, @longdesc as specified in HTML4 can be added to both <img> and frames/iframes: "This attribute specifies a link to a long description of the image. This description should supplement the short description provided using the alt attribute." "This attribute specifies a link to a long description of the frame. This description should supplement the short description provided using the title attribute, and may be particularly useful for non-visual user agents." (http://www.w3.org/TR/html4/index/attributes.html) Equivalent 'description' functionality for tables is supplied by @summary: "This attribute provides a summary of the table's purpose and structure for user agents rendering to non-visual media such as speech and Braille." (http://www.w3.org/TR/html4/struct/tables.html#adef-summary) SVG uses a slightly different approach, with the <title>/<desc> elements: "The combination of the hierarchy and alternative equivalents can help a user who cannot see to create a rough mental model of an image." (http://www.w3.org/TR/SVG-access/#Structured) Figure is new to HTML5, and could conceivably also take the @longdesc attribute, once we get @longdesc reinstated into HTML5 as a conforming attribute. Should I file the bug, or will you? <smile> > 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? Yes. See above. > > Also, ease of use seems to be missing from that page. Can you elaborate more on what you mean by "ease of use"? In the user-agents primarily targeted by @longdesc, the majority of screen readers announce the presence of a longer description (with no user intervention) immediately after announcing the value of @alt, at that point however the end user is presented with the choice of pursuing the longer description, or skipping past it - a key consideration. Choosing to follow a link is pretty easy. <grin> In the few visual instances we have today, the link to the longer description is presented to the user in the contextual menu (this is native in Opera, and what the Firefox plug-in currently does today). In talking about this issue at both the SxSW and CSUN conferences earlier this month, there seemed *to me* to be a general consensus that this is both useful and appropriate behavior/rendering. Specifically, the developers of NVDA agreed that this was what they envisioned as a right way forward, and should this be added to Firefox (for example) they could happily support it in NVDA. Earlier today, Sean Hayes (Microsoft) posted a MSDN blog on how to extend similar functionality to Internet Explorer (http://blogs.msdn.com/b/accessibility/archive/2011/03/25/configuring-inte rnet-explorer-to-handle-longdesc.aspx) so it seems that there is also a conversion around a standard activation mechanism for sighted users - the contextual menu. I think this is a Good Thing(TM). The one missing piece today is finding a way to signal to sighted users that they can actually access something useful from their contextual menu when images have longer descriptions (in other words, in-document discoverability). Since one of the design goals of @longdesc was to provide a specific functionality *without* having a visual impact on the authored page (the dreaded and shunned "D" link), we have a fairly serious conflict of requirements. However, it seems to me that placing an icon or other indicator in the browser chrome would be a workable compromise, one in fact that Chaals McCathieNevile has illustrated with his recent Opera extension (https://addons.opera.com/addons/extensions/details/tellmemore/1.2/). I am talking with another developer to take this model and create a Chrome extension as well, and once Patrick Lauke comes up for air, he agreed to look at adding something similar to his existing Firefox plug-in. Other suggestions on how to more easily address these conflicting requirements are welcome. > > 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>). I see no reason why it cannot be an attribute for these elements as well: we are writing a new spec, so we can certainly add this to the spec - there is still lots that needs to be done with <canvas> today to ensure accessibility, so let's include <canvas> as an element that the @longdesc attribute can be added to. (Show of hands?) > It isn't very user friendly. How so? > Lots of people > seem to misunderstand it to include the actual describing text rather > than a link to it. Jonas, the web of 1997 is very different than the web of 2011. The majority of web developers today do not hand-code their sites, even if many members of this mailing list still do. WYSIWYG editors have pretty much solved this problem years ago by indicating to the author a "browser for the file" function when adding @longdesc to complex images. (http://rebuildingtheweb.com/en/offer-to-save-longdesc/) Finally, as the March 11 email to the Chairs from Geoff Freed indicates (http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html), professional content producers (such as those involved in the ePub initiative, or the US federally funded DIAGRAM Project) are interested and ready to use @longdesc to meet their own existing requirements. I personally have faith that should they start using @longdesc, they will do so properly and accurately, greatly increasing the pool of useful and well constructed @longdesc descriptions. (Is it important to note that these authors are primarily interested in richly structured documents, and *NOT* web-app development?) For these reasons, I must discard your assertion here; we have ample evidence to suggest that this is not going to be a problem moving forward. > 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. Can you back that assertion with proof? In fact, one of the use-cases presented, "Describing a Logo" (http://www.d.umn.edu/~lcarlson/research/ld.html#uc-01) having the longer description as one page, with multiple pages pointing to that same resource *is* the use-case. (Content authors would agree with this, this being after all a Best Practice for both JavaScript and CSS today - write it once and share it across all documents.) Having @longdesc capable of pointing to an external URL is in fact also the reason why aria-describedby cannot alone solve the problem statement. The second use-case, "Describing a Cartoon" (http://www.d.umn.edu/~lcarlson/research/ld.html#uc-02) is another instance where the artist does not want in-page text interfering with the visual rendering of the page; it makes little sense to recreate the dialog of a series of cartoon speech bubbles directly after the cartoon from a visual/design perspective. In these cases, we simply will not get what we need, as the 'design' of the artist in this instance will always trump the 'data' requirements if those requirements become too onerous. > > 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. Actually, the problems are more serious than that. As you note, the text value of aria-describedby cannot be semantically structured; no lists, no tables, etc. In the case of a complex pie chart, the best way of 'textualizing' the image would likely be via a table. Aria-describedby cannot do this. As well, as implemented today, the value string of the @aria-describedby attribute is immediately read aloud by consuming technology (screen readers): there is no end-user choice to listen to it or not. This could actually lead to a very degraded experience for non-sighted users; again it is not the optimum choice. (I will concede that we might want to talk to screen reader vendors about this as well) Finally, we must remember that ARIA is and always has been considered a bridging technology until "native semantics" provided the required functionality, a point that was made in the prevailing Change Proposal you and I both contributed to: http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements (At the writing of that Change Proposal you did not indicate that you disagreed with that statement, and I hope you've not changed your mind on that now.) Why-ever then would we remove a native attribute (@longdesc) and replace it with a bridging solution? Seems like backward movement to me. > 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. Not really. In fact, there have been a few high-level thought discussions about introducing a new aria attribute in a future ARIA dot Next version that would better solve the problem (rather than attempting to re-work a functioning attribute). However, when you spec out the requirements, it looks and feels *JUST LIKE* @longdesc. None-the-less, should HTML5 not retain @longdesc, it is a possible strategy to implement needed functionality from outside of the actual HTML5 specification - we could simply back-door @longdesc functionality (called something else) via ARIA. Seems kind of silly and childish to me (not to mention breaking backward compatibility) - we should admit that @longdesc serves a function, that retaining it in HTML5 causes no harm and adds benefit, and move on. > > 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. All of the problems described here can be solved by @longdesc today by simply making it conformant in HTML5 (and maybe getting the browsers to do something useful with it). @longdesc can point to an IDREF as well as an URI which could/would be a semantically structured page that could support ruby, tables, lists, hyperlinks and more. You are instead suggesting that we re-invent the wheel by modifying ARIA attributes very late in the ARIA Recommendation Process (and not as comments to the ARIA WG, but rather here in the HTML WG). (I have also heard that "opening a new page/tab" is poor usability. If I am to accept that, then what to do? Perhaps something like what Dirk did here: http://blog.ginader.de/dev/jquery/longdesc/examples/webaim/index.php - see the iFrame example, and it's use of XHR a.k.a. AJAX. Some people see 'broken', I see challenges, and thank Dirk for implementing my proof-of-concept idea.) > > 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. Jonas, aria-describedby is not broken. It does what it was designed to do, and it was never designed to replace native functionality we've already had since 1999 (with @longdesc). > > 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 flip that around and suggest that if @longdesc continues to have problems, we should own those problems and fix them. That is what was done with <b> and <i> previously (where new 'semantics' were added to what initially were presentational elements), and frankly the only real problem that remains with robust support of @longdesc is that the mainstream browsers fail to do anything useful with @longdesc, fobbing it off on AT tools or plug-ins. (And if plug-ins is the way to go, so be it: the browsers need not do anything more than let HTML5 move forward with @longdesc being conformant. Cost to browsers? $0.00. Benefit to users and concerned content authors? Immeasurable. I would prefer that browsers however worked towards better results: invest the little time and effort it takes to get this right.) If we are to believe the design goals and principles of HTML5: * evolution, not revolution * users, over authors, over implementers, over code purity * paving cowpaths ...then the only logical conclusion that can be reached is that we need to tighten up on @longdesc, and not seek to re-invent the wheel here. As a member of one of the browser teams on this list, I challenge you to go back to your developers and look to find a good solution to support an attribute that has been with us for over a decade. This really shouldn't be so hard or complicated. JF
Received on Saturday, 26 March 2011 02:22:04 UTC