Accessibility: Take 2
Posted by Kyle Weems on September 17, 2009As I first discussed here, and then officially announced here, I’ve been upgrading CSSquirrel with accessibility features to help make this site more accessible for the vision-impaired. I first considered the idea several months back, when John Foliot approached me with a code sample that I could use to give the comic an alternative long description for screen readers. I’ll admit that I didn’t act on it at the time, though, because it seemed like a low priority. How many blind people read comics?
I realized the mistake in my complacency when I received my first blog comment from a blind user here, where he was testing his ability to post despite the CAPTCHA that was present. At that point I realized that if even one person was visiting my site and incapable of at least knowing what was happening in the comic, they were getting a severely degraded experience, which was a disservice on my part.
My growing awareness of how frustrating such a thing would be is borne out in my Squirrel in the Dark post. As a result of this, I went about adding an aria-describedby attribute to my comic’s image tag. Later, based on feedback from a JAWS-10 user and with another suggestion by John, I doubled up with the addition of the longdesc attribute to the image. In both cases, the value for the attributes is an URL for a separate transcript page.
Thinking all was well, I congratulated myself and went back to poking fun at the HTML5 process and spent a lot of time drawing people in spandex.
Of course, it wasn’t that easy.
First, a new accessibility problem had reared its ugly head. When I built the site’s CAPTCHA, I had actually taken vision-impaired users into consideration and provided description text of each image to allow them to select the proper one for the CAPTCHA (mind you, not including the word that the CAPTCHA asked you to match with the image). However, when someone tabbed through the page’s links and fields, the tabbed indexing would go out of order, going through the other input fields for the comments at a different time than the CAPTCHA itself, making the whole affair confusing.
Secondly, I learned that the aria-describedby element isn’t meant to direct to other pages (which I think is a bit silly of a limitation, but I’m not an expert at these things), but rather should contain the ID of an element on the page containing a description. It’s quite a difference, and one I’ll admit I made by failing completely to do enough homework on the matter in advance.
I’d thank Henri Sivonen for his “bug report” on the aria-describedby issue, but he chose to use the issue to draw a comparison to the Super Friends‘ list of concerns (and its initial posting to a blog instead of the WHATWG mailing list) and neglected to mention it to me directly. So instead I’ll thank Laura Carlson for drawing my attention to my error, Arve Bersvendsen for sharing his opinions on alternate techniques, and Steven Faulkner for suggesting a way to use aria-describedby to link validly to off-page content. I know others contacted me about the error, but I’m sorry to say I don’t remember all the names at the moment.
My solution, therefore, was what Steven suggested in the W3C mailing list. The aria-describedby attribute on the image tag now has a value that is the ID of an anchor on the page. That anchor then links to the comic’s transcript page. The anchor is hidden by CSS to avoid distracting sighted users. You can examine a recent comic, like this one on the Super Friends, to see it in effect (if you’re on a normal browser you won’t notice much unless you view the page source).
The CAPTCHA’s messed up tabbing issue turned out to be an easy fix as well. Stéphane Deschamps pointed out in a comment that there was tabindexes on the form’s fields, which was causing the tab order to go screwy. I didn’t know these existed, having failed to examine the blog software’s default fields very much. Now that he’s pointed it out, I’ve taken them off, hopefully making the CAPTCHA less burdensome.
As I’ve stated in the past, I’m a non-expert at pretty much everything that doesn’t involve vector squirrels. However, I have an appetite for absorbing as many web-related skills as possible to help better the web through direct effort or comic-related advocacy. One of these areas of the web that I realize that I need a great deal more knowledge about is accessibility, and it’s a deficit that I seem to share with almost every designer or developer I meet.
Having admitted my deficiency, I’d like feedback on this issue, if you have it. Does the updated aria-describedby technique for serving the transcript actually use the attribute properly? Is the CAPTCHA usable by vision-impaired visitors with approximately the same level of annoyance all people feel when they use a CAPTCHA? Is there another feature on the site that causes accessibility issues that I haven’t mentioned or considered?
To those who contact me with these problems, thank you. I’m in your debt.
Tags: accesibility, aria-describedby, CAPTCHA, henri sivonen, john foliot, laura carlson, longdesc, Stéphane Deschamps, steven faulker
[...] http://www.cssquirrel.com/2009/09/17/accessibility-take-2/ a few seconds ago from web [...]
Wow, I like your thoroughness and honesty on all this!
The captcha is indeed much more usable, tab-wise.
As for the aria-describedby, its use is most probably mostly involve speaking out the element and then its descriptor. It’s how the examples I’ve seen so far of popins or form elements work.
For a form field, it reads: 1. the label, 2. the type of form field, 3. its aria properties if set (invalid, etc), 4. the content of the blurb mentioned as aria-describedby.
Come to think of it, I wonder if using aria-described by for a longdesc doesn’t push it too far away from the attribute’s aim (especially considering longdesc does work well in browsers and screen readers that implement it).
What was your primary objective, by the way? Learn about ARIA or try to find a way to get rid of the longdesc, it being threatened by the html5 work in progress?
[...] http://www.cssquirrel.com/2009/09/17/accessibility-take-2/ a few seconds ago from IdentiFox in context [...]
Slightly off-topic (but still within the accessibility realm), I noticed that the title for every link starts with “Link to”, wouldn’t that be slightly annoying for screenreader users? I think the screen reader informs the user that it’s a link, so it would be saying “Link: Link to an accessibility comment on this blog”.
Stéphane – The primary objective is to provide lasting support for vision-impaired readers to have easy access to the transcript of a comic, without bloating the comic’s page with a large hidden field filled with the descriptions and transcript. I’ve been using both attributes in an attempt to allow support for older and newer screen-readers (it’s my understanding that longdesc is in the process of being put out to pasture, so I didn’t want to rely on it alone.)
I’m not certain if the aria-describedby solution I have works properly or not (aka, if it provides a clear path to the link that brings up the transcript), hence the feedback requests. If not, I’ll need to tinker with it more.
Gonzalo – Definitely still related to the topic. In the past I’ve been instructed that you should always start link alt attributes with “Link to”… but I don’t recall if it was advice meant for some strange SEO practice at the time, or accessibility or what. Any screen-reader users able to offer feedback? Is it obnoxious, or helpful?
I’ve not had any luck getting aria-describedby to work, either on your comic or on other test sites. I’ve come to believe it’s not yet supported either by browsers or screen readers (not sure which, maybe both), but I’m standing by to be corrected on that. I’ve tried JAWS 10, WindowEyes 7.0 and NVDA 0.6p3.2 using IE 8 and Firefox 3.5. None of them announce the describedby text or its availability in any way.
Longdesc is working though. I don’t think NVDA supports it yet, but JAWS and Window-Eyes both announce the availability of a long description and invite the user to read it by pressing another keystroke (Enter in JAWS, Alt+Enter in Window-Eyes).
@Terrill – I’m not sure how widely supported aria-describedby is, but I figure someday readers will use it, hence the inclusion. Thank you very much for the feedback. Does the longdesc attribute properly send you to the transcript?
I did a (very) quick search on Google for aria-describedby and found three entries: one said that the key for it is F1, other said “JawsKey+F1″ (I don’t know what that means) and the other one said it’s Insert+F1. I don’t have JAWS so I can’t test it, unfortunately.
I think I should read more on this, I have two books which I got recently but I couldn’t find the time to read them, I’ll try to read one this weekend. One is “Web Accessibility: Web Standards and Regulatory Compliance” by J. Thatcher, M. Burks, et al., and the other one is “Maximum Accessibility” by John Slatin and Sharron Rush.
I’m sorry for the double comment but I found something quite interesting: a set of ARIA Test Cases where there’s an entry on JAWS for aria-describedby but for the indentation I don’t know if that is the expected behavior, or the current one:
JAWS:
If described by is used on a fieldset (group box), JAWS speaks the description when focus is placed on a control within the group box for the first time.
If described by is used on a control, JAWS displays the description when the user presses JAWSKey+F1.
The short answer: Yes. The Longdesc on your comic does the job in both JAWS 10 and Window-Eyes 7 (nicely written description by the way!)
The long answer is here: http://tinyurl.com/blogdesc
I didn’t intend to draw a comparison with the Super Frinds. I was just lazy and assumed you were reading the #whatwg logs in search for material for the comic anyway.
Well, I had a chat with My Good Friend John (a.k.a. $%%(&*^%&$ Foliot, inter alia) between the adding of aria-describedBy and the subsequent addition of longdesc. There’s probably a chain in there somewhere (not to mention whips and oil and whatever else keeps John’s bike running).
Thank you for your efforts in working on accessibility for this. Thanks in particular for the longdesc thing, since there really is a shortage of people who post stuff the HTML 5 public reads who actually use longdesc.
It’s true that the aria version requires the content to be on the screen – longdesc merely *allows* that. But then, it is in theory possible to change that since ARIA is in working draft. The argument against is that ARIA is currently meant to work on a page or application, but I don’t think it’s such a hassle even in a widget installed and running offline, since it can hold the descriptive content offline too. In certain situations it may even make sense to be able to collect the descriptions in a seperate document (rather like a glossary) for ease of maintenance.
The argument Lachlan gives against allowing this is that it leads to invisible metadata, which in the general case is often badly-maintained. However, these things are, in the general case, non-existent, so looking at what people (and squirrels) who actually use these things do might be more important than extrapolating from the skewed dataset of “everything in existence”.
Anyway, since I am in the process of looking carefully at how to do our ARIA support in Opera, and therefore looking once again carefully at the spec (after several years of not getting close to most of the nitty-gritty), your experience and thoughts, and those of your readers, are interesting and valuable.
I have some other thoughts (and talked to John about them), but it is very late. Assuming I managed to solve the semantic puzzle, I will try to get back to the topic later…
PS Thanks for the comic in general…
Both http://www.cssquirrel.com/comic/?comic=35 and http://www.cssquirrel.com/comicscripts/script35.htm are great. And this could be such an incentive in language (whether native or secondary) classes: asking students to produce verbal descriptions of comics that work would get more echo if they knew it could be of real use to people who can’t view the comics.