Development and UX from Michael Mahemoff. Maker of Player FM. Previously: Google, BT, O'Reilly author.

Menu

Build Accessibility in the Workflow (London Web Standards Meetup)

I went along to the London Web Standards Meetup last night and attended a presentation on accessibility by David Owens. What I liked about this talk was David’s grounded pragmatism. It was immediately apparent he makes real products in the real world. There is a good community of accessibility people with that attitude, which makes a good balance to some others who are prone to broadcasting accessibility edicts from ivory towers. These range from the naieve – the ever-popular “though shalt use alt tags” – to the loony – “javascript and video is forbidden due to accessibility regulations”.

I captured a few notes, hardly exhaustive, but a few interesting points I picked up during the presentation. (As with the Shirky notes from last week, please excuse the slap-dash style, this was taken on my phone.)

<

p>
Accessibility

Not just disabled, also if tired, on mobile, ill, hangover 🙂 etc

Don’t just build for disabled, make it easy for everyone… Usability and accessibility go hand in hand.

Accessibility at each stage

Visual design:
Recently changed mind about text resized widgets (three different sized As), conventional view is not to them because browsers already let users resize text, BUT be pragmatic esp where users have multiple disabilities which would make it hard to invoke zooming

Dev:
Flash, don’t throw out just because not everyone can use it

Standards:
Eg consistent headings
Heading structure

Skip links (skip to middle of page etc):
Not actually so useful for blind users as they tend to load a list of links, but useful for someone who can’t mouse around easily
Access keys. Browser supported keyboard shortcuts. BBC myweb myway site is a very good source to link to, to help users understand how to use them. Also BBC use the same set across their asseys and American sites are using similar conventions so a pattern of standards is emrging (1=search etc)

Interaction:
hijax POSH first (plain old semantic html), then JS later
BUT with screenreaders how do you tell user something’s changed above the part they’re listening to?
WAI-ARIA standard is helping as a stopgap until html5 defines standard regions of the page and control types, and areas likely to update.

Colour:
Not just colour blindness but failing eyesight. (David will be posting links to some good resources he demo’d on the meetup page I believe.)

Video:
Making controls accessible and calling to and from javascript not flash based – then you have better keyboard access. Also transcribe content (good for seo too), it’s dirt cheap with services like castingwords, at least for smaller content. But don’t hold back on posting the video just because you’re waiting for transcription.

I also had a colleague ask me to see if anything comes up about accessibility with maps and lo and behold, David demonstrated a google maps mashup which had some good accessibility work performed on it. I think he’ll be posting the link on the meetup page. The main interesting thing was that all the points-of-interest are shown in a text-based list which will show if Javascript is disabled, and you can hit tab to rotate between the POIs on the map.

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff