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.

2 thoughts on Build Accessibility in the Workflow (London Web Standards Meetup)

  1. I could perhaps have been a little more clear on what I meant by that.

    I was specifically thinking that the document landmarks in WAI-ARIA matchup quite nicely with some of the new html5 elements. For instance nav/navigation, article/acticle and complimentary/aside.

    Gez Lemens has written a great introductory article at the dev opera website which is well worth a read.

    Introduction to WAI ARIA.

    (I’ve also added the links I mentioned to the London Web Standards Meetup page)

Leave a Reply