Having just returned from the premiere conference on accessibility and technology, it was inevitable that I would find myself brimming with new ideas. This year, it started quite early, when John Foliot caught me and told me he had something he’d like for me to do.
John being who he is, I was already quaking in my comfortable shoes.
The history of longdesc in HTML5 is complicated: the decision to keep the attribute required many long arguments and defense of the use case — and one of the arguments against it was that nobody was using it. Well, one reason nobody used it was that it was hard to use and hard to know it was in use on a page. Hard to implement with no apparent use? Hopefully, this plug-in can help change that.
Supporting longdesc
What he wanted was support for the longdesc attribute in my WordPress accessibility plug-in. There was an existing plug-in that offered that support, but it hadn’t worked for a while, and hadn’t been updated in over 2 years — abandon-ware being a common problem in all areas of open source software.
That plug-in simply offered the ability to take the existing WordPress “description” field for images and generate a page for that image, which the longdesc attribute would then point to. Simple, straightforward — and dependent on browser native behavior to expose the existence of the long description to users.
Adding a user interface
Since browser support for longdesc is really not that great (e.g. bloody lousy), I ended up conversing further and noting some proofs of concept for longdesc user interfaces that Karl Groves and Dirk Ginader had described for experimentation.
What I’ve ended up doing is somewhat a composite of both ideas, and literally provides more than one option for the site admin to choose.
The default option is a jQuery-driven solution that overlays the long description on the image. It adds a wrapper around the image, then injects a button and a description field into that wrapper.
The alternate option is just a link: it injects a link to the description after the image.
Both options require JavaScript – it is possible to do inject the link directly in the HTML (HyperText Markup Language), but I haven’t chosen to do that at this point.
Testing and known issues
I’ve tested this with NVDA and Firefox and with about a dozen themes. I’m releasing it with incomplete testing for the simple reason that I know I can’t find every issue in the time I have – I’m hoping others will give me that feedback!
One known issue, which occurs in some themes, has to do with themes that only attach the default WordPress image alignment styles to the img element. Since I’m moving the classes from the img onto the div wrapper, if the alignment classes are only attached to the image, the alignment breaks. I’ve implemented generic classes in the WP Accessibility styles to compensate for the alignment, but I’m not overwriting padding and margins, as well; just ensuring that the images will float as expected.
Have something to contribute?