A presentation on the parallels between responsive design and accessible design By George Zamfir (good_wally).
Hopefully this will go up on his account at Slideshare shortly, I’ll add a link later.
He has been working on Scotiabank Group websites, which are very involved and detailed sites with dynamic content and navigation. Other areas of the public facing website were challenging due to having a lot of content.
Two years after a re-design, they had to do another one to make it responsive!
As the accessibility person, he didn’t want to break the accessibility during this process.
He already had some experience with RWD with some (client based) side projects.
Assistive technologies don’t care much about design. E.g. screen readers don’t care about rounded corners. Even magnifiers will adjust things to make it easier, sometimes stripping things out. ‘Reader’ and RSS readers do similar things.
Responsive design also does that. It isn’t about making rounded corners fit a small screen.
There are four main parallels he wanted to draw:
- Content trumps design
- Catering to user context
- Keyboard friendly = touch friendly
- Designing for edge cases
Content trumps design
In principle, content should trump design, regardless of screen size.
If you define disability by what people can contribute to society, who’s more disabled, Stephen Hawking or Rob Ford? (Lots of laughs!)
Accessibility is also for an ageing population. A local Mayor in his area is 93 years old, she probably needs some accessibility services when running a city of a million people. Another example was his dad, who almost switched energy providers because he couldn’t find the bill on their website.
Context has changed, we aren’t all sitting in ergonomic chairs in front of a computer, we might be on the sofa with a tablet.
There is a lot of overlap, e.g. captions for people in a quiet office, or reading glossy phone screens in the sun. Using a device in one hand is now a given context, but that might also be because you only have one hand.
The W3C’s “after” website is accessible, but on an iPhone the links are so small it’s very difficult to navigate. On small screens you make the touch-targets larger.
Keyboard friendly = touch friendly
Keyboard accessibility translates to touch friendly. He asked an agency he worked with about keyboard accessibility and they said:
Oh yes, it’s keyboard accessible! To open the menu press cntl-shift-alt-f2-W-T-F!
In the banking context, they realised that lots of users were logging in with the iPad, and because keyboard accessibility was in place it worked by default. This was something that had been done for accessibility, but helped with responsive design.
There was one exception, where we had fake controls instead of native ones. It looked the same, but didn’t quite work on touch. So: try to use native components.
Design for edge cases
In a project, he started with designing for the smallest and largest conditions screen first. If you start with the harshest conditions first, the in-between states are then not as hard. This is very similar to accessibility where you design for keyboard access and zooming.
Consider accessibility as the edge cases, and things in the middle work themselves out.
I thought in general the principles rang true to me, it would have benefited from some details on some common cases, e.g. VoiceOver on iOS. However, it is an interesting discussion and nice to have the general principles called out.