These are the notes from my workshop on 2 October 2012 at the Technical Communication UK (TCUK) 2012 conference. I called it “Getting Down and Dirty with Accessibility and Usability”. Unlike the slides for my keynote presentation at the same conference, the slides in this workshop were text heavy. (Slides are at the bottom of this post.) They were meant as notes – talking points – for the workshop. Each slide covers areas where technical communicators can begin to apply accessibility and usability right away.
The workshop was called hands-on, but I ended up talking for most of the session because many attended out of curiosity and had no actual projects for hands-on practice. There were many great discussions and questions and answers during the 2.5 hours of the workshop. (If any my TCUK12 workshop attendees come to TCUK13 and want to discuss accessibility “hands-on”, we can always hack in a corner of the bar! My treat!)
Due to the poor accessibility on Slideshare – presenter notes aren’t pulled out for the transcript, I am posting my own notes here (with the slide text for context). Other presenters express frustration about the downside of sharing slides. There is often little context and image-heavy slides can be meaningless even to people with sight.
I had extra slides so I wouldn’t run out of material. These are marked as such.
Introduction – Slides 2, 3, 4, 5
Today’s workshop. The pretty pictures are on your screens, not in these slides! What can be fixed right away and how? Where can you find more resources? We’ll look at what accessibility and usability tricks you can put in your toolkit. We’ll also discuss ways you can apply your new skills – I used the logo of TCUK to symbolise the field of technical communication. Finally, I had to be slightly corny and mention “enlightenment” – the dawning of new knowledge in the minds of many more technical communicators. I used a personal photo of a winter sunset to illustrate this point.
I mentioned how it all just takes one step at a time to implement accessibility. Here’s an article that demonstrates the one-step-at-a-time approach.
BAD Demo – Slide 6
The Before-and-After Demo from W3C: http://www.w3.org/WAI/demos/bad/
. This is an excellent training/teaching resource. I had it downloaded on my laptop in case the wifi didn’t work. It demonstrates a site without and then with accessibility improvements. I referred to it a few times during my presentation. Kudos to the people in the Education and Outreach Group at the Web Accessibility Initiative who developed this great resource!
Good examples of accessible websites – Slide 7
- List of accessible sites compiled by Terrill Thompson – with explanations!
- French languages sites that are classified as being accessible
Alt text – Slide 8
I always point everyone to these links. They explain everything. Written by smart people!
- HTML5: Techniques for providing useful text alternatives
- Appropriate Use of Alternative Text
- The case of the missing alt attribute
And remember alt="" (Read the links to find out what that means.)
I had one more reference from @vdebolt with tips on using appropriate alt text that some of you might enjoy.
Title attribute – Slide 9
<title> is a misused attribute. Get the low-down in this excellent link:
Using the HTML title attribute
Longdesc – Slide 10
The <longdesc> is going through turbulent times, but I say go for it. There is a good article on longdesc from WebAIM.
I listed tables on my slide, but that was a mistake. Just read the article and you’ll get it straight. For more food for thought, read RNIB’s article on longdesc from 2008.
Jim Thatcher made a marvelous favelet tool for checking web accessibility. You can try it for checking longdesc, too. (I haven’t tested that.)
Headings and Structure – Slide 11
This should be an easy one for technical communicators. Use headings! Use structure!
My talking points were
- Skip to main content links (blind and keyboard users)
- Sequence and patterns (non-linear navigation – reading order)
- Style guides (for consistency)
My support notes:Note that screen reader is only interested in HTML, not CSS, therefore structure (web standards) is important. Headings are the easiest way to identify structure. Proper structure and good use of headings aid navigation. Use semantic markup and good navigation. Keep things logical. Visual readers interpret the graphic presentation for navigation: headers, location, etc. A screen reader needs similar info because screen reader users need the same thing for navigation.
ARIA is especially helpful (more links later). There are 8 document landmark roles to help screen reader users navigate and identify purpose of content as explained in article on WAI ARIA document landmark roles.
Skip to main content links – beneficial not only to blind, but to keyboard users who want to get to a link in the main article and want to avoid all the navigation and advertising links. This is a useful article about skip to main content links.
It’s a myth that vision impaired users access everything in a linear fashion or listen to everything on the page. They can skip around on a page (if the structure lets them) and it helps if there is a pattern. Vision-impaired users access things sequentially – learn layout and become familiar. Frequent layout changes must be a pain! VI (vision-impaired) users listen to all on-screen text – they can skip around, too, listening to just enough to decide whether to stay or go. Source on VI reading patterns.
BBC has a standards and guidelines semantic markup guide they use. You can base your own in-house style guide on that, for example, to ensure that everyone uses markup correctly and consistently: BBC guidelines for semantic markup.
Lists – Slide 12
Lists: <ol> , <ul> , <li> , and CSS styling
Always use <li> , <ol> , <ul> , and style with your CSS. Why people don’t do this, I don’t know. It’s clean! Rumor has it that this is a problem so I mention it to make sure you don’t make this mistake! Reference: WebAIM article on lists.
Keyboard-only access – Slide 13
- Do it with a keyboard
- WebAIM on keyboard-only access
Can you do everything with a keyboard? Everything? I use Hootsuite.com for scheduling tweets, but I am unhappy with certain inaccessible aspects of the product. I must use a mouse or I cannot complete the login procedure. Same problem with Tweetdeck (which I don’t use). I cannot log in with a keyboard. This is crazy when social media is proving to be a great and growing community for people with disabilities – mouse-only means many are excluded. I’m told only onClick works with both keyboard and mouse. Why not use classic HTML where possible? This can solve your mobile needs, too. Making everything keyboard accessible is a basic improvement that can go a long way.
Color – Slide 14
Remember that color and color contrast and alternate indicators play together. Never use color as your only delimiter. In Denmark, it’s estimated that 8% men are colorblind and 0.5-1% women are colorblind. (Danish resource on colorblindness stats in Denmark.) Moral: consider what colors you are using. This color contrast check from snook.ca is fantastic and very popular. Helps you determine whether you comply with standards, too. A keyword is contrast – watch out for color contrast. wearecolorblind.com is a great resource about color issues.
Labels – Slide 15
Labels need to be made correctly. Always identify the form field with an id attribute. Then, create a label element for each field. Connect it to the input field’s id using the ‘for’ attribute. I took the images on the slide from this video demonstrating coding labels for accessibility. Using placeholder in form fields is optional, but read this article for an opinion on why placeholder is a bad idea with labels.
Link text – Slide 16
DO NOT USE CLICK HERE OR READ MORE.
I rant the reasons why in my blog post I don’t want to read more or click here.
Plain Language – Slide 17 and 18
- Design to Read
- US: Center for Plain Language
- US: Plain Language in the Federal government Plain Language in the Federal government and a Plain Language checklist
- UK: Plain Language Commission
- Link to the European Commission’s Information Providers guide – leads to info about accessibility
- Link to the Translation and Drafting resources from the European Commission – go to the link for "How to write clearly". It takes you to the EU bookshop
- Direct link to the EU bookshop and the Write Clearly booklet
- Smashing Magazine article about 16 pixels body copy
- zeldman.com with large type
- Article about Zeldman’s Web Design Manifesto
- WebAIM article on tables
- Screen readers read tables from left to right, from row to row
- <summary>, <th>, <scope>
- How-to: Frank Palinkas’ article on creating accessible datatables/ and Isolani’s article on structured tables (with a football pools example!)
- Keyboard-accessible YouTube controls
- JW Player
- Easy YouTube Player
- Accessible Media Player
- And no <autoplay>!
- ARIA (application, banner, complementary, contentinfo, form, main, navigation, search)
- WAI ARIA document landmark roles-document-landmark-roles/
- Screen readers and ARIA landmark roles
- Using WAI ARIA landmark roles
- Color Contrast and more – a Mozilla add-on
- Fireeyes from Deque
- Functional Accessibility Evaluator
- Web Developer Extension from Chris Pederick
- Web Accessibility Toolbar for IE from The Paciello Group
- W3C WAI Tool List
- Learn: Iheni on screen reader testing
- Plan: spotlessinteractive.com on a screen reader test plan
- More at Learning how to use and test with screen readers
- Provide text alternatives for non-text content.
- Provide captions and other alternatives for multimedia.
- Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
- Make it easier for users to see and hear content.
- Make all functionality available from a keyboard.
- Give users enough time to read and use content.
- Do not use content that causes seizures.
- Help users navigate and find content.
- Make text readable and understandable.
- Make content appear and operate in predictable ways.
- Help users avoid and correct mistakes.
- Maximize compatibility with current and future user tools.
- Understanding WCAG 2.0: A guide to understanding and implementing Web Content Accessibility Guidelines 2.0
- How to Meet WCAG 2.0: A customizable quick reference to Web Content Accessibility Guidelines 2.0 requirements (success criteria) and techniques.
- What is a screen reader? Article from 2005 so some product details are outdated. Read it for what it is and how it works.
- Just Ask: Integrating Accessibility Throughout Design. + print
- Sign up for the discussion list at WebAIM
- Opera Web Standards Curriculum in association with Yahoo! Developer Network
- Web Standards Project’s InterACT (site/book)
- University of Minnesota at Duluth newsletterTypography, information architecture, usability, accessibility, maintained by @laura_carlson
- Accessibility for Web Writers series
- Be equitable
- Be flexible
- Be simple and intuitive
- Be perceptible
- Be informative
- Be preventative
- Be tolerant
- Be effortless
- Be accommodating
- Be consistent
- Advice on involving people with disabilities in usability testing
- Using personas to teach accessibility
- @RogerJohansson + 456bereastreet.com
- @webaxe + webaxe.org
- @silviapfeiffer (all about video)
- @MarcoInEnglish / @MarcoZehe + marcozehe.de (Firefox)
- @jared_w_smith + WebAIM.org (with discussion list, too!)
- @iheni + iheni.com (mobile)
- @stevefaulkner + paciellogroup.com/blog (ARIA, HTML5)
- @dugboticus + alistairduggin.co.uk
- @AccessifyForum + accessifyforum.com
- Yahoo! accessibility code library
- Accessibility topics at Web Standards Sherpa
- Mozilla ARIA resources
"How to Write Clearly" in 23 languages
Text Size – Slide 19
Tables – Slide 20
Tables are for data. Not layout. Data. Make sure your tables are accessible. Because I don’t make tables regularly, I forget how to code them properly. I always have to look up the code, but I do look it up and make it accessible. Not doing so seems so wrong. The two resources here are a great help. Remember: use <summary> where you can also list number of columns and rows. Learn to love <th> element and <scope> attribute!
Captioning – Slide 21
I’ve given talks about captioning at TCUK10 and at the first a11yLDN unconference. I’ve pointed people to my presentation for captioning guidelines. Download the slides to get my presenter notes. They are vital – and not visible otherwise in Slideshare.
Note: from slide 22 until my thank you at slide 35, I went very, very fast. I was running out of time and did want to close with the image on slide 34 and my closing credits. The slides are now getting heavier text-wise. They are meant as starting points for the topic in the slide header. I had so many resources for many topics. It was painful culling them!
Video – Slide 22
These are resources for accessible media players. Some are standalone players made to be accessible. The first link is a way to make YouTube accessible. The issue is that screen readers cannot access the controls for the typical media players, which means that they cannot access the video. And yes, blind people want to access videos to hear the information. Even a blind and deaf person could enjoy a video if it was captioned properly so there was an interactive transcript.
Autoplay – Slide 23
DON’T USE AUTOPLAY! It’s hard or impossible to stop using screen reader. If a page is opened in a different tab, the sudden noise can be confusing, startling, or conflicting. I.e. cognition issues. (And that applies to everyone and anyone. DON’T DO IT!!
ARIA – Slide 24
These articles do all the explaining about ARIA.
Testing and Evaluation – Slide 25
There are many tools out there to help you evaluate your site. It is good to try them all at first and get a feel for what works best for you. Having a couple installed is not a bad idea. They can back each other up. These can catch the major bloopers. Use these tools to catch the low-hanging fruit. But… Never uninstall the best overall evaluation tool you have – your brain!! If testing excites you, consider joining the Browser Testing and Tools Working Group.
In a comment on the page for the Web Developer Extension, I found this helpful video/article about using the tool. See also articles in the accessibility testing category from Karl Groves. And, finally, the achecker testing tool.
PS WebAIM has a new WAVE in beta. Check it out at http://five.wave.webaim.org/.
Screen reader testing – Slide 26
Standards – Slide 27
WCAG 2 at a glance – Slide 28
This one of many WAI teaching resources.
WCAG 2.0 – Slide 29
Learn-more resources – Slide 30 and 31
Get to know how a screen reader works by reading the first article. The "Just Ask" link is an online book that is also available in print form. It is also a great way to start your journey into accessibility.
The first two links are teaching/teach-yourself resources.
The third link is an excellent newsletter that comes out every week. It comes highly recommended.
The last link is the number one link I’d recommend to any technical communicator – along with the “Just Ask” book mentioned elsewhere here.
10 Principles – Slide 32
These ten principles were written by Sandi Wassmer and are in people-speak and another way to get the mindset for building accessibly. View the 10 principles of inclusive web design online where there is also a link to download a PDF.
My favorite quote – Slide 33
When universal design processes fail to include, consult with, and listen to the people we are actually designing for, we also fail to design effectively.
– Lisa Herrod
The source of this quote is http://scenariogirl.com/inclusive-design/the-social-model-of-disability. It has been broken for a while due to ISP issues. I keep referring to the link until it works or a new one replaces it.
Image of man taking a photograph reflected on a metal surface – Slide 34
In summary, think about how your work reflects back on you. The man in the photo sees his reflection on the shiny surface of a button on a lamp post in the city. Think back to the starting thought about quality – what quality will you see in your work?
Official closing slide – Slide 35
Thank you for listening! Questions?
@kmdk / @stcaccess
Extra – Slide 36
All of the following slides are extras that would have been used as I saw fit on the spot. They are “as is” for interpretation.
Mobile – Slide 37
User diversity – Slide 38
Test with real people!
Users are different. But are you aware of the variety? When you test your systems, test with real people who have real disabilities. Personas can be a substitute in some cases. Personas can help teach accessibility. Developers are more likely to respond if they can see how people can be affected by their inaccessible web pages.
Demo of an accessible infographic and alt text – Slide 39
I (heart) WebAIM.org
(Slide 39 through 44 show screenshots that illustrate good use of alt text and an accessible infographic. It is meant for situations where there is no wifi.)
Confession: I love WebAIM. They have so many resources I can learn from. Let’s start the discussion with an example from WebAIM: an infographic of web accessibility tips for designers (and developers). A pretty .png picture. Useless to someone with little or no vision.
The pretty picture is available on their site – ALONG with a text version…
The text version is the text that is in the image we first saw. All the text was pulled from the picture and put into this alternate form. At the top of the screen shown here is a link to an accessible version of the .png file…
Someone else – Chris Throup – made an accessible version of the picture. Looks the same.
But the code reveals how there is no image in what looked like an image on the previous slide. It’s just code – machine-readable code.
This slide shows Chris Thorup’s code with – at the bottom of the slide – a sample of the WebAIM code for the text version. The same message gets across, but in 2 different ways. The WebAIM sample showed icons echoing the original image. However, those icons use alt text to tell a person using a screen reader what that icon represents. All in all, a lovely real-life example of making something accessible to many different needs.
Twitter+ Resources – Slide 45
People are probably the best resources of all. This is the tip of the iceberg here. I could talk for hours about the people I think you should follow. It caused me pain to not include some people. Some may be at a far higher level of coding knowledge than you are comfortable with. Break out of your comfort zone! Or share these links with your favorite developers. They are people well worth following. Note that the last one also has a forum where you can ask all sorts of questions related to developing accessibly.
Coding resources – Slide 46
Great coding resources for anyone wanting to get down and get real dirty! The Mozilla ARIA resource is huge and growing. Start your ARIA explorations there.
Special thanks to John Kearney and Neal Dench for helping me finish this blog post. October has been crazy busy for me so the posting process got a wee bit too delayed.
Thanks to the people of the WebAIM discussion list – especially Birkir! – who have been an inspiration for other presentations that led up to this workshop.
Thanks to TCUK (and dear David Farbey) for inviting me to be a keynote speaker. That led to me daring to give this workshop.
Material in this workshop builds on material from past presentations I have given. There are some messages (for example, the one about alt text) that still bear repeating. As long as there are things out there that are broken – and shouldn’t be, these messages need to be repeated.