Home

Redesign of Barry McMullin's example

Monday, 23 August 2010

I would redesign complex images like Barry McMullin's example as follows:

1. I would remove the text “A model of reflection for children's palliative care”;
2. redesign the rest of the image so text is at a readable size;
3. create a caption with the previously removed text below the image: “Figure x: ...”;
4. turn the caption into a link to the long description;
5. but still add a longdesc attribute with the same URL because the relationship with the long description should be programmatically determinable.

In other words, for images that can use a caption I would still use the same approach as in a report that I wrote six years ago. This is basically because of the poor browser UI for @longdesc. So we should think about a better rendering of longdesc content in user agents. Gregory Rosmaita has pointed out that the need to navigate away from the “current” page to the “longdesc page” is a problem with current browser implementations; an in-document rendering would be preferable, possibly per user settings. We should look into two pieces of UI:

1. How does the browser expose the presence of longdesc (not just to screen reader users)?
2. How should the description be rendered to the user?

I can't think of many ways to expose the presence of longdesc. How about making an img with @longdesc keyboard focusable, putting it in the tab order? @longdesc contains a link, so that doesn't seem very artificial. It would also be nice to expose the presence of @longdesc to sighted users who might benefit from a long description. A widget that appears onhover would help to some extent, but I don't think you can assume that sighted users hover over every complex image. The second part of the problem is fetching and rendering the long description itself. If the long description is on another page, the browser could fetch that page and render it. But for in-document rendering, you probably want just the description itself and nothing else, so the browser needs to know where the description begins and ends. This is easiest when the longdesc page contains only the description and when there is only one longdesc page per image. If there is other content on that page, a browser would need to be able to reliably extract it, but producing code that results in an unambiguous DOM seems too much to ask for many tools and developers. Finally, there is the rendering issue. If we assume that the long description can benefit users without AT, a non-visible rendering (i.e. just passing the description to a screen reader) is not sufficient. So what are the UI options? Some kind of overlay? A non-modal dialogue? (A modal dialogue?) Rendering in a side bar? To be continued... (Time to get some dinner and go to bed.)