CSUN 2013 notes

The 28th Annual International Technology and Persons with Disabilities Conference, better know as CSUN 2013, took place February 25 to March 2, 2013. I attended the general sessions portion and provide here the notes I took from some of the sessions I attended.

WCAG Guidelines – What about the Users?


  • Birkir R. Gunnarsson
  • Hinni Hreinsson

Screen reader usage and trainer

  • Many users run multiple screen readers
  • 21% of users had formal training with screen readers
  • 80% use their screen reader webpage summary feature

Familiarity with landmarks, headings, and table navigation

  • 1/3 are familiar with and use landmarks
  • 60% are familiar with and use headings
  • 61% are familiar with and use table navigation hot keys to browse tables

Web page exploration strategies

  • 80% of users use tab and arrow keys to explore pages
  • 8% of users use TAB and arrow keys exclusively
  • Large part of the user base rely heavily on TAB and arrow keys to navigate a webpage
  • Most also have other means of navigating

Suggestions for improvements

  • Web developers: use markup clearly and efficiently

Be the Fireman and not the Cop


  • John Foliot

Current problems

  • Lack of accessibility planning / pre-planning
  • Stakeholders already on the defensive
  • Tight deadlines
  • No budget allotted
  • Content being developped without web acccessibility in mind

Resistance to change

  • Confrontation
  • Rejection
  • Avoidance
  • Insincerity

Finding the champions

  • It takes a cultural shift
  • Key is good communication and communicators

The law of the few

“The Tipping Point” by Malcolm Gladwell

  • Find:
    • ‘Connectors’ – know everyone, have done everything within the company
    • ‘Mavens’ – tech gurus, hardcore geeks
    • ‘Salesman’ – promoters, persuaders

Communication skills

  • Be likable, stay positive – all the time!
  • Connect – find mutual points of interest
  • Solve problems and build trust – teamwork starts with you
  • Create positive experiences – make learning fun
  • Identify and recruit the few

Establishing the systems to get you there

Tackle technical challenges

  • Standardise CMS use so you can solve problems in one place
  • Track bugs
  • Use frameworks to get accessibility built in
  • Create custom tools for internal use
  • Standardise evaluation tools

Tackle cultural challenges

  • Provide detailed expectations of outcomes, not dictate the solution – encourages creativity
  • Set realistic goals and expectations
  • Lay out the efforts as challenges not consequences
  • Don’t worry about the pursuit of quality – don’t let perfect be the enemy of good
  • Set timelines and milestones
  • Foster empathy and understanding
  • Brownbag events – invite actual users with disabilities

Addressing financial challenges

  • Be honest about how much it will cost
  • Scaled question – the longer you delay the more it costs

Transition towards a team based approach


  • Identify the responsible people
  • Identify bottlenecks in each group independently

Establish training and internal resources

  • Motivation – internal awards, recognition, etc.
  • Document knowledge – wiki etc.
  • Aim for consitency of implementation

Legislation, policy, and best practices

  • Accessibility is a governance issue, and a shared responsibility
  • Appeal to pride instead of fear
  • Create a policy: work with existing standards, avoid re-inventing the wheel
  • Lose legal threat as a last resource

Measuring success

  • Avoid checklist mentality
  • Avoid apprearances of making concessions and sacrifices
  • Avoid overly long and complex accessibility reports
  • Make accessibility more than a QA process
  • Work with milestonesL test early and often
  • Be specific with what you ask for but generous with what you accept
  • Celebrate successes, both great and small

Agile and Accessibility: Theory and Reality


  • Karl Groves

Waterfall approach of accessibility

  • Accessibility is a thing that intrudes at the end of every phase
  • If accessibility isn’t specified as part of a phase then accessibility isn’t going to get handled for that phase
  • Accessibility isn’t part of the discussion, it is an approval step

How do agile and accessibility work together?

  • Definition of Done
  • Inherently user focussed
  • Inherently quality focussed
  • Inherently collaborative

Tools and techniques

  • Test-driven development
  • Daily stand-ups
  • Definition of Done

Case Study: Fortune 100 Healthcare Company

Some Design Up Front (SDUF)

  • Spec work on what pages should look like
  • 95 initial reenderings (snippets of UI elements)
  • 9 page types
  • 10 sub-layouts

Traditional scrum

  • Accessibility team members assigned to several scrum teams
  • Before each story was considered complete it had to be cleared by accessibility team member

Deviations from the process

  • Underestimated scope
  • Underestimated resources
  • Untrained resources
  • Executive staff unwilling to adjust to meet evolving needs
  • Agile-fall!

Lessons learned

  • No project management system will assure success without knowledge and skills required to be effective
  • Accessibility can be integrated into any process
  • You must follow the process to realise the benefits
  • Time spent up front building accessible componenets and patterns is good accessibility ROI (still expect to refactor later)

Accessibility in Firefox for Android


  • Marco Zehe
  • Eitan Isaacson

Android versions

  • Android upgrade is slow
  • Most common version is Gingerbread (2.3)
  • Latest version, Jelly Bean (4.1 and 4.2) is 3rd most common

Android accessibility

  • Jelly Bean has very good support
  • Gingerbread and earlier have very basic support

Firefix for Android

  • Each version has improved support for native navigation options
    • D-pad navigation (2.3+)
    • Explore By touch (4.0+)
    • Gesture navigation (4.2)
  • Additional navigation options built in to Firefox
    • Keyboard quick navigation (2.3+)
    • Gesture quick navigation (2.3+)
  • Firefox adds support for native navigation options to earlier versions of Android
    • Explore by touch backported to 2.3
    • Gesture navigation backported to 2.3

Infographics – Making Images Speak


  • Ted Drake


  • Poor support
  • Hidden content for most users
  • Allows for good structure


  • aria-labelledby or aria-describedby
  • Removes structure, treats content as a string


  • Announces element as image, reads alt text
  • Can still use content hidden with display: none;
  • Long pause before content is read, easy to miss


  • Does not label element as a graphic up front, replaces content with transcript
  • Announces element as a graphic at the end of the transcript

Include transcript

  • Allows for good structure
  • Repeats content in the infographic
  • Can be visually hidden with CSS clipping

Toggle transcript

  • Provide a structured transcript
  • Hide content by defauly
  • Add control to show the content

Transcript link

  • Add visible link to transcript

Implementing Accessibility Testing At The Enterprise Level


  • John Foliot
  • Mitchell Evan

Testing matrix

  • Prioritise Assitive Technology / Browser combinations based on likely use and instance of problems

Test plan for each feature or page:

  • How to test
  • Expected results
  • Actual results
  • Notes


  • Use a bug database, not monolithic reports
  • Browser / AT matrix

Template for future projects

  • Kickoff: confirm the plan, meet & greet
  • Ground rules for visual design
  • Collaborate with UX design
  • Visual accessibility analysis
  • Collaborate with developers
  • Test

Mozilla Firefox OS – Mobile Open Web Platform


  • Marco Zehe
  • Eitan Isaacson

Operating system

  • Written entirely in HTML, CSS, JS, including apps and even the web browser
  • Open source
  • Linux Kernal
  • No SDK required for development


  • Get the next billion people on to the web
  • Initial launch in Central and South American countries
  • Hardware somewhere between feature and smart phone specs for affordibility

Accessibility in Firefox OS

  • Bad news: first version won’t have a screen reader
  • A screen reader is coming soon…
  • It will share the same core accessibility engine as desktop and Android versions of Firefox

Plain Language: Usable Content for Everyone


  • Angela Hooker

Common content problems

  • Language that needs explanation (Shakespeare)
  • Unusual structure of language (Yoda)
  • Sometimes institutions (such as government) dictate the content
  • Overly wordy content
  • Jargon that hides meaning
  • Slang or regional terms
  • “Pedantic content” – big showy words where simple words will do
  • Forgetting the audience

Plain language is…

  • writing content that people can easily understand the first time they read or hear it
  • usable and meets users needs so they can act on it
  • not forcing your users to read content several times to understand it

How can plain language help?

  • Your users will be loyal
  • Will widen your site’s appeal, audience, and influence

WCAG 2.0 principles of accessibility

  • Plaing language supports POUR
  • Plain language is ‘Understandable’ in ‘POUR’
  • Plain language makes your content accessible for all

Plain language is not…

  • dumbed down content, it’s meeting the needs of your audience

Don’t forget…

  • People with low literacy skillls
  • Pleaople with low language proficiency
  • People with cognitive impairments
  • People with dyslexia
  • People who are Deaf or hard-of-hearing
  • People who are aging

What you can do

  • Write for your specific audience
  • Write for the average reader
  • Dont’ be clever, make it simple
  • Assume audience is intelligent but don’t assume they’re familar with your topic
  • Inverted pyramid method: put the most important information at the top and the background information below
  • Be concise – cut out excess / filler words
  • Use minimal text and short sentences
  • In print people write to tell a story, but online we should write about topics so users can complete their tasks


  • Write in active voice, avoid passive voice
  • Use simple verb tense and base verbs (present tense)
  • Avoid ‘hidden verbs’ such as ‘provide assistance for users’ instead of ‘assist users’
  • Use complete sentences
  • Use words and terms that your users are familiar with
  • Provide direct insturctions
  • Talk with your users: use personal pronouns
  • Avoid jargon, or explain it when necessary
  • Use ‘must’ instead of ‘shall’ in requirements


  • Test with users
  • Conduct A/B testing


  • Always consider your users’ needs first
  • Your users want to complete a task
  • Talk directly to users
  • Use everyday terms
  • Don’t follow trendy content practices
  • Each medium (mobile, dekstop, app, video, podcast) may require tailored content
  • Read your content aloud
  • Test your content
  • All of these help you incorporate accessibility throughout your project lifecyle

Speaking out – public speaking made easy

Last night I attended Speaking out – public speaking made easy organised by Laura North and Christian Heilmann with David Bell, Katie Streten and Christian speaking. Here are my notes.

David Bell (Merrill Lynch) – Focus on presentation styles and contexts

  • Contexts – style and delivery vary according to type of meeting (small, large, conference) and your role within it (pitching ideas, asking questions).
  • Preparation – the key to being relaxes is to be prepared, focussing on:
    • who your audience is
    • message you want to deliver
    • materials – appropriate slides
    • objective – what is the purpose of the meeting / presentation
  • Style – presentation style determined by:
    • presenters personality
    • audience
    • subject
  • Summary
    • connecting with audience is vital
    • preparation is the key to being relaxed
    • be selective with your material – think big picture
    • your style will develop over time and comes with practice
    • presentations are performances – sometimes they go better than others
    • everyone gets nervous – you aren’t the only one

Katie Streten (Imagination) – Reasons not to like public speaking, and some suggestions for dealing with them

  • Reason 1 – no one will be interested in what I have to say
    • they are there
    • you have been asked to speak
    • think what you can give them
  • Reason 2 – I will go blank
    • prepare – write script long hand
    • read it to people are yourself
    • write card notes
    • highlight key moments
    • don’t practice too much
  • Reason 3 – I’m afraid that everyone will find out that I’m a fraud
    • you’ve been asked to speak
    • everyone thinks this
  • Reason 4 – I will look out over the crowd and freeze
    • don’t look at the crown, pick 3 spots to look at
    • place a friend at the back to smile at you
    • they are more interested in the talk than in you
  • Reason 5 – I will lose my place and stall
    • use card notes
    • practice
    • audience are on your side
    • ‘fess up
  • Reason 6 – I will ask something that everyone else understands
    • most other people are thinking the same thing
    • that’s their problem
    • you are helping someone in the audience
  • Reason 7 – It feels artificial, it should feel like a conversation
    • audience hates it to
    • say ‘Hello’
    • move your arms at waist height
    • don’t have a rigid script
  • Powerpoint
    • bullet points
    • pictures
  • Conclusion
    • people genuinely want to hear what you have to say
    • think about your audience – what can you give them?
    • if all else fails.. try and remember the detail of 1 speech you have heard in your life – no-one can

Christian Heilmann (Yahoo!) – How to inspire as a speaker

Chris has written his own post on the event, which includes a link to his slide deck and video of his presentation.

  • Have a different point of view
  • Find the story that makes the difference
  • Audience and information are more important than the speaker
  • Knowing what the audience needs is the most important part of the presentation
  • Having the right mindset is important – you have nothing to lose
  • How do you get this mindset?
    • know your subject
    • own your talk
    • practice
  • Practice by:
    • loud reading in different character voices
    • listening to audio books
    • listen to yourself
    • Powerpoint Karaoke
    • lightning talks
  • Get inspired by good examples
  • Thinks to avoid
    • imitation
    • reading your slides
    • forgetting the story
    • blinging it up

Accessibility 2.0 – A million flowers bloom

Last Tuesday, 2009-09-22, I attended AbilityNet’s Accessibility 2.0 conference at Microsoft’s London Victoria offices. Here is my writeup of the notes I took in a mostly unedited form. I hope you can make some sense of it!

You can get the speakers presentations as they become available from AbilityNet.

Greg Fields (RIM) – Designing Accessible Mobile User Interfaces

  • Use native UI components where possible.
  • Be mindful of colour and contrast; minimum 7:1 contrast.
  • Respect user preferences by inheriting global settings.
  • Error messages should help users recover from the error.
  • Context menus should have the most frequently used option as the initial focus.
  • Consistent navigation, controls, interactions throughout the application.
  • Progressive disclosure: make users aware of the number of step in a process.
  • Organise information by type, meaning, etc.
  • Limit ‘chunks’ of info to 3 to 5 items.

Christian Heilmann (Yahoo!) – Neither Technology Nor Accessibility Is Dark Magic

  • Accessibility movement does not have impact / momentum.
  • Social web can be user to spread the message.
  • WiiHab – technology making a difference.
  • Web 2.0 is for everyone, not just geeks.
  • Branding holds us back, acknowledge and work with the competition.
  • Make links understandable and predictable.
  • Knowledge + Passion = Accessibility.
  • Teaching means being open.

Access Beyond the Desktop

A panel consisting of:

  • Lucy Dodd (BBC)
  • Henny Swan (Opera)
  • Veronika Jermolina (AbilityNet)
  • Greg Fields (RIM)
  • Damon Rose (BBC Ouch)
  • Julian Harty (Google)

Greg Fields

  • Moblie surpasses landline in some markets.
  • Serverside speech recognition can work with fewer client side requirements.

Henny Swan

  • Concerned about making the same mistakes as on the desktop in 1998.
  • Crossover between mobile and desktop accessibility.
  • WAI-ARIA, CSS3, media queries, HTML5 and geolocation technologies need to be ported to mobile.
  • Progressive enhancement for mobile.

Damon Rose

  • Mobile is a ‘killer app’ for blind people.
  • Mobile sites must not destroy the web experience.


  • Same site with mobile stylesheet.
  • Allow personalisation and port preferences or allow different preference profiles for desktop and mobile.
  • Mobile accessibility requires collaboration between hardware vendors, software vendors and site / application developers.

Lisa Herrod (Scenario Seven) – Understanding Deafness: History Language and the Web

  • 1 in 7 (about 9 million) are deaf ro hard of hearing in the UK.
  • Big ‘D’ Deaf: culturally deaf, may not speak English as a first language.
  • Little ‘d’ deaf: does not identify with the deaf community, English as first language.

Steve Faulkner (Paciello Group) – Accessibility with HTML5 and WAI-ARIA

  • HTML5 semantic elements and WAI-ARIA landmark roles do not serve the same purpose.
  • Some HTML5 enhancements can be implemented with ARIA now e.g. HTML5 ‘required’ attribute is equivalent to aria-required=”true” attribute.
  • Canvas accessibility has fail! Bolt on not built in.
  • Audio, video and canvas fallback content should be outside the element – ignore the specification advice.

Mark Boulton (Mark Boulton Design) – Inclusive Design

  • Accessibility ‘experts’ need to educate designers better.
  • Accessibility is put off as ‘someone else’s problem‘.

Saqib Shaikh (Microsoft) – Silverlight Accessibility

  • Same accessibility challenges and requirements as any other development – colour contrast, semantics, etc.
  • Detects high contrast and operating system colours.
  • Works with browser zoom.
  • Controls are ‘lookless’ – their function is separate to their appearance.

To Comply Or Not To Comply

A panel consisting of:

  • Kath Moonan (AbilityNet)
  • Bim Egan (RNIB)
  • Léonie Watson (Nomensa)
  • Mark Boulton
  • Lisa Herrod (Scenario Seven)
  • Christain Heilmann (Yahoo!)


  • Accessible products can still have beautiful design.
  • Guidelines are a starting point not the end, and shouldn’t stop innovation.
  • Responsibility for accessibility should not just lie with developers.
  • Test early, test often, with as diverse a group of users as possible, with and without disabilities.


This was yet another great day for accessibility learning in the UK, following on from Techshare the previous week and Standards.Next at the weekend. Every presentation had something to say, and as usual it was good to get a chance to talk with like minded individuals throughout the day.

The day brought up a lot of discussion over how best to create mobile sites: same markup with a mobile stylesheet or a separate implementation based on the same content source. This is not my area of expertise, but I find it an interesting question nonetheless. I’m looking forward to hearing more on this.

There is one point I would like to comment on. Mark Boulton said that the current crop of accessibility experts, who in the main are developers, need to do more to educate designers. Kath Moonan said that developers were heroes for being the ones to learn the skills needed, and it was also said that developers should not be the only ones with whom responsibility for accessibility lies.

At the moment developers are expected to know about accessibility not just when it comes to the code they produce, but also in terms of design and content, which they are not necessarily involved in producing. While I agree that developers can help designers catch up this can’t last. Developers cannot continue to be the single point through which accessibility is researched and knowledge distributed.

It seems to me that designers need to not only take responsibility for the accessibility of their work but also for their own education. Those of us who have been thinking about such things for longer can start the ball rolling, but beyond that we should be working towards developers and designers having a basic but broad knowledge of accessibility on top of which each group builds its own specialist knowledge.

Standards.Next – Cognition and accessibility

On Saturday, 2009-09-19, the second Standards.Next event took place at City University in London, organised by Henny Swan and Bruce Lawson. This time the subject was ‘Cognition and accessibility’, a much overlooked topic.

I had the distinct pleasure of speaking along side some remarkable and talented people: Antonia Hyde, Jamie Knight and David Owens.

There have been several good write ups of the event already, but I’ll add my thoughts as well. The ‘key points’ are what I took from each speaker, not necessarily what they intended to be the most important.

Antonia Hyde – Accessibility beyond code

Antonia has rare access to testing time with users with learning difficulties, people who benefit tremendously from the internet. The work she does is invaluable in teaching us how we, as developers, can help. As you may be able to tell I’m a big fan!

Key points:

  • Describe content and controls literally – ambiguity is a barrier to comprehension
  • Combine icons with text to re-enforce messages
  • Colour coded blocks of content or sections of a site can enhance structure

Jamie Knight and Lion – Autism, the Internet and Antelopes

Before Standards.Next Jamie was interviewed by Henny about his experience of being a web developer / designer with autism. This was eyeopening and truly astonishing – the idea that stress could affect a person’s ability to talk for the next seven months came as a shock to me.

On the day he added to this with an entertaining talk and further Q&A.

Key points:

  • Fast paced action and speech in video can be hard to follow
  • Screen readers can help process content
  • Instructions must be in a literal form

David Owens – Lessons Learned Doing Usability Testing

David has recently been involved in user testing, something that few developers are able to do enough of. It is great that he works for a company that sees the value in this, because it is something that even big organisations often skip.

Key points:

  • Users can’t always remember how to do things that they have done before
  • Font re-size widgets still have a place, even though they duplicate browser functionality
  • Put flash controls before the flash so that users are made aware of them before they give up

Me! – Content and Cognition

It has been very interesting to read what other people took from my talk. In a way I felt that I was giving a summary of many of the points the other speakers had made. It reinforced my opinion that so many of the things we need to do to make our sites usable applies to most of the groups that we, rightly or wrongly, put users in.

The points I was trying to make were:

  • Avoid distractions
  • Mix content types to reach a wider audience
  • Provide feeds or APIs to allow others to transform your content in to new forms

It also kicked off a number of interesting discussions.

  1. I advised that popup windows should be avoided. Kath Moonan added that lightboxes, which are like in-page popups, also test badly with users. It appears that Alastair Campbell may be planning some research on this matter.
  2. I advised to not create elastic layouts, because this makes font-resize work like page-zoom rather than these being separate things. This removes choice from users. Some may disagree with me but I think it is a valid argument. Mike Davies has asked me to write more about this for one of his sites, so there will opportunity to flame me at a later time.

My slides are available online.

Other posts

BarCamp Liverpool – Day Two

Day two of BarCamp Liverpool started with ‘Let’s talk about sex’, an open discussion where, amongst other things Ian Forrester asked if geeks can talk about sex in an mature and adult way. The answer is ‘no’! This was probably the most entertaining part of the BarCamp, but possibly not for the right reasons.

In ‘How to pimp yourself’ Richard Quick talked about how to promote yourself as a freelancer, or as a company. He gave his 7 tips for success, and we then moved on to a discussion which expanded on his ideas. The information doesn’t directly apply to me these days, but there was plenty about how best to behave at conferences to make this a good session for me.

Cristiano Betta then talked about ‘Using wordpress for OpenID’. The WP-OpenID plugin allows you to use your WordPress blog to login to OpenID consumers. We followed this up with a general discussion on OpenID, particularly how to spread its use to the masses.

The last session I attended was ‘Don’t Just Change the World… Improve It!’ from Adrian McEwen. Adrian had returned to Liverpool late in the Capital of Culture year, and he talked about the changes he had seen, and his ideas on how we can make a difference in our communities.

With all that serious business out of the way all that remained was the obligatory game of Werewolf. I’d only played once before, and with a much smaller group, so this was great fun. I was killed while I peacefully slept, but it was almost as much fun to watch.

And with that, my first BarCamp was over. I will be back for more.

BarCamp Liverpool – Day One

I’m waiting for the second day of BarCamp Liverpool, so I thought I’d take the time to write down my thoughts on day one.

I didn’t really know what to expect from a BarCamp, but whatever it was this event wasn’t it! Out of 200 places I guess about 100 people actually turned up, a sizeable number, but a little disappointing event even if you take in to account the inevitable wastage when tickets are free.

First job: book a slot to speak. My chosen subject: accessibility. I thought I’d stick to what I know. I’ll write about how that went in a separate post.

After an introductory speech from the organisers I moved on to a talk about ‘The 3D Web’ from Stephen Clibberly. I have to say I am not convinced by this technology, but it was interesting none the less.

Next, ‘How to be a dead good speaker’ from Phil Winstanley. As I would be speaking for the first time here I though that this would be a good subject for me. Realisation that I had done most of the things I shouldn’t have done in my slides didn’t help with my nerves at all, of course!

‘Readable Perl’ was after lunch (food for 200 people, eaten by 100!). Now I’ve disliked Perl for about 8 years, mostly because I had to work with badly written code. Seeing examples of how nice Perl can be might have changed a little bit, but I think I’ll stick to PHP and Python for now.

‘Getting started with Arduino – How to build a twitter monitoring Alertuino’ by Adrian McEwen has a fairly self explanatory title. Adrian modified a toy laser gun to activate whenever someone made a direct tweet to a particular address. I’m surprised I haven’t heard of Arduinos before. I may have to invest in a kit.

Then little me…

After this I took part in a ‘Privacy open discussion’ led by Alistair MacDonald. 4 of us spent 45 minutes giving our opinions on where the line is between personal and private when we blog, tweet, or otherwise post online.

Finally was a demo of Pacemaker form Ian Forrester. Now, I don’t share Ian’s taste in music, but this session was great fun. The Pacemaker is an impressive bit of kit, I don’t think it is the iPod killer that Ian would like it to be, but it is pretty cool.

And then on to the party. Free drinks courtesy of Microsoft, who also provided prizes for a raffle and startup competition. Their products are not entirely appreciated by an audience that seemed to be primarily Mac and Linux users, but I don’t suppose that is their fault.

And so day one came to an end.

First Post!

After many years of procrastination, I have finally started my first blog.

What it is going to be about remains to be seen, but I suspect I’ll be writing about web development, particularly accessibility and usability, and might include the odd political rant and my views on various human rights issues.

This is a weekend for firsts for me. First blog. First blog post. And also my first BarCamp, which will hopefully involve my first crack at technical public speaking. I’m attending BarCamp Liverpool, the first in the city and billed as the biggest in the UK so far. Post #2 will in all probability be about day 1.