Quiz 1.1.7: Long Descriptions redux
Should we use long descriptions or try something different?
During an update to a very large intranet design, I included a large number of accessibility features in the basic templates. That’s good, as far as it goes. Features in templates enable basic features, but aren’t enough to assure accessibility of all the content.
The company’s quarterly financial results were written up a few weeks after the new designed launched. The quarterly results are presented as a collection of pages, an overview, and then one from the head of each of the many business units. Each report is several paragraphs about the good things that happened, the key newsworthy points of the quarter, and sometimes advice on what we need to do better.
Each report includes a sidebar holding 3 to 5 bar chart images noting various performance factors, quarter to quarter comparisons, or annual trends. You’ve seen them, so I don’t need to include any here: revenue, profits, return on investment, market share, etc. Our charts are especially attractive, all being done in a common design apparently by a single hand. They are beautiful, but alas not accessible.
When I became aware of the accessibility problem, the charts were simply images stacked into the sidebar. A few even had ALT text that said something like “bar chart.” Some, but certainly not all, were actually mentioned in their companion article text. None were described in any detail.
The first remedy we considered was long descriptions, the traditional WCAG recommendation. The content producers immediately protested having to make yet more pages, but we pressed on with some demo pages. Then we discovered what we consider a fatal flaw. The assistive technology vendors are not consistent. Jaws launches a long description page as a new window (shame on them). So, we accommodated by casting the long description pages into our pop-up window template which includes very convenient “close window” buttons. The fatality occurs when someone using IBM Home Page Reader (HPR) uses a long description page. HPR doesn’t launch a new window, but navigates to the page in the same window. Hitting that “close window” button does indeed close the window, ending the browsing session completely. Oooops!
Andy Clarke talked about this last September and decided to use a footnote solution instead. He suggested using a footnote on the same page, and hiding it from visible display. Of course, that assumes a sighted visitor can discern all the fine details from our especially attractive bar charts.
Q. Would you use long descriptions or something else?
- A Use long descriptions without any “close window” link in the longdesc page. Depend on the user knowing how to handle their Assistive Technology.
- B Include good descriptions of the image right in the text near them. In our case, the executives had other “messages” to convey and did not want to cede space to chart descriptions.
- C Describe the chart with ALT text. If you can. Try describing a 5 element bar chart in 60-64 characters.
- D Add a caption below the image which describes the chart. Like ALT text, space constraints may be a problem.
- E Use a footnote at the bottom of the page / article. Determine whether to hide it depending on the clarity of the actual image. Sighted users night benefit from the details within the footnote.
June 19th, 2005 at 8:51 pm
I would not use long descriptions, but more likely a mix of C, D and E (I see the combination of these as being similar to “B” but providing only key information and using the footnote/link for detail).
Hard to say. Some charts have a lot of value and allow one to compare many things and draw many conclusions. Other charts are just used as a way to highlight something visually… draw attention to where one data point stands out from the pack. I think the approach should depend on the information being conveyed, more than it being “a chart”.
If you intend someone to get all the data from the chart, compare and contrast various values, then a data table should be provided that gives comprehensive information. It may be possible to produce an “accessible chart” in some cases (e.g. image bars in a data table), rather than a single image.
On the other hand, if a chart is intended to highlight one or two key points, those key points should be highlighted in the alt text. Simply describing the values of the data would be a literal representation of the chart, without the added meaning a chart can convey so effectively.
June 20th, 2005 at 2:47 am
E: endnotes
I think endnotes might be easier to use if you want to compare two images/charts.
June 20th, 2005 at 8:51 am
What about an accessible bar chart constructed using tables, rather than an image? Here is a great example: http://www.standards-schmandards.com/index.php?2005/02/06/14-accessible-bar-chart
You can even go further than simple bar charts with one bar per column as this example shows (scroll down a bit):
http://www.globalissues.org/Geopolitics/ArmsTrade/BigBusiness.asp
June 20th, 2005 at 9:59 am
That is a tough one. If I had access to users of the assistive technology, I’d go with E. If not, I’d go with A. Because if I went with something ‘new’ like E, I’d want user-acceptance by the assistive technology users. Otherwsie I’d probably go with the WCAG recommendation, figuring that the vendors (and/or users as well) read or are aware of this standard.
June 21st, 2005 at 3:51 am
I still choose A. Why? Because the WCAG is a published standard and this gives us all–assitive technology vendors, web page designers and browser makers–something to aim towards. Otherwise we’re all just shooting randomly at different things.
We call all look at the WCAG and say, “Well, that’s not the way I would’ve solved the problem but at least I know everyone is now focusing on supporting that way, flawed though it is. I’d better do the same.”
The browsers did a lot of catching up in the 5 years to support standards. In the last three or so years the web designers did a lot of catching up. Now it’s the assistive technology vendors. My advice is to be patient and stick to the published standards.
June 21st, 2005 at 6:51 am
Using the “stick to the published standards” logic, we should be finding “D-links” all over the net. We don’t. They were a bad idea and the W3C has made them deprecated in WCAG 2.0.
Sticking to the published standard didn’t help wood spoked wheels survive very long on automobiles, did it?
We can stick to the published standard, or we can help improve the published standard with better techniques.
June 21st, 2005 at 11:43 am
B is my general solution when an image - chart or whatever - need description for it all to make sense.
E, visible to all in most cases, looks like a good option.
June 22nd, 2005 at 11:19 am
Primary E, but only visible to the screen readers. Reason being that the images are all artwork related.
I can also see method C working, but that would depend on how descriptive you want to be. Trying to describe artwork in 60-64 characters would be pretty tough to effectively do.
(In fact, trying to describe any artwork to someone who is visually impaired is tough to do.)
June 23rd, 2005 at 8:27 am
I had a similar problem when consulting for a large UK supermarket. I eventually went with linking up the image to a longdesc-type page. An added bonus was that the image content effectively became searchable. The full description of the image could also be of benefit to sighted users who want more detail than the images immediately provided without squinting.
One modification to A is to write out your close window link with Javascript, checking for the presence of a window.opener. That way if the window isn’t a popup, you don’t get the close link…
June 30th, 2005 at 10:34 am
I am surprised no one mentioned the “D” link which is a link using the link text “D” (I have seen various incarnations of this, D, [D], (D)) to the longdesc page (in case a browser doesn’t support longdesc).
Another possibility might be to create a caption and then “hide” it using left: -1000 so that it doesn’t take visible space but is available for screen readers. I know that Andy Clarke uses (used? I haven’t checked lately) this method to “hide” the Skip Nav link.
July 1st, 2005 at 11:03 am
Jules: No-one has mentioned the “D” link, I imagine, because we have all read Joe Clarke’s book, which rubbishes them, and therefore disregarded them from our thought process. Actually, I have never seen a “D” link on a site anywhere so it surprises me when you say you’ve seen various incarnations of their usage.
I am however intrigued by the idea of hiding a description off-left of the screen.
July 3rd, 2005 at 6:24 am
Jules: We asked about d-links as bonus points part of the previous quiz. No one reports seeing them used in real life. The W3C is marking then “deprecated” in WCAG version 2.0. They’re a failed idea and even the W3C recognizes that fact.
Phil: We covered quite a few hiding techniques in a series of testing. “Off left” is my favorite. Check out the results and examine the test cases for coding techniques.
August 22nd, 2005 at 8:20 pm
sfmuni.com uses the D link, which we learned of from the VTA, San Jose’s transit agency. If it’s been deprecated, we’ll look at replacing it. I’d say A, no close window button, or else put the data table next to the graph and don’t bother hiding it or putting it elsewhere.
December 31st, 2005 at 10:53 am
thank you for interesting articles
January 5th, 2006 at 11:27 pm
I like B best, even though it takes up territory. If the charts do not add to the page, but merely repeat information, they don’t need to be there. it they add to the information, there should be space to describe them.