“So long as a web-based
system is inaccessible, it
suffers from quality
problems and we should
focus on quality.”
– Karl Groves
Structure and headings
• Skip to main content links (blind &
• Sequence and patterns (non-linear
navigation - reading order)
• Style guides (for consistency)
• ARIA (application, banner, complementary,
contentinfo, form, main, navigation, search)
• Screen readers read tables from left to
right, from row to row.
• <summary>, <th>, <scope>
• How-to: http://dev.opera.com/articles/view/
creating-accessible-data-tables/ & http://
(with a football pools example!)
When universal design
processes fail to include,
consult with, and listen to the
people we are actually
designing for, we also fail to
– Lisa Herrod
• WAVE http://wave.webaim.org/
• Color Contrast and more https://addons.mozilla.org/da/ﬁrefox/addon/juicy-
• Fireeyes http://www.deque.com/products/worldspace-ﬁreeyes/download-
• Functional Accessibility Evaluator http://fae.cita.uiuc.edu/about/
• Web Developer Extension http://chrispederick.com/work/web-developer/
• Web Accessibility Toolbar for IE http://www.paciellogroup.com/resources/
• W3C WAI Tool List http://www.w3.org/WAI/RC/tools/complete
WCAG 2 at a glance
• 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 ﬁnd 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 and How-To
• 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.
• Yahoo! accessibility code library: http://
• Accessibility topics at Web Standards
• Mozilla ARIA resources: https://
• What is a screen reader? Article from 2005 so
some product details are outdated. Read it for
what it is and how it works. http://
• Just Ask: Integrating Accessibility Throughout
Design: http://www.uiaccess.com/accessucd/ (+
• Opera Web Standards Curriculum in association
with Yahoo! Developer Network: http://
• Web Standards Project's InterACT (site/book)
• U of MN Newsletter: Typography, information
architecture, usability, accessibility, maintained by
“Mobile Matters Most”
• For iOS app builders - discusses Apple
Interface Builder. http://mattgemmell.com/
• Updates for Android developers: http://
• Be equitable • Be preventative
• Be ﬂexible • Be tolerant
• Be simple and • Be effortless
• Be accommodating
• Be perceptible • Be consistent
• Be informative
Thank you for listening!
@kmdk / @stcaccess
&#x201C;Byg Tilg&#xE6;ngeligt&#x201D; or &#x201C;Build Accessibly&#x201D; by Karen Mardahl for Community Day 2012 on 10 May 2012. communityday.dk\n
Confession: I love WebAIM. They have so many resources I can learn from. \nLet&#x2019;s start the discussion with an example from WebAIM: an infographic of web accessibility tips for designers (and developers).\nA pretty .png picture. Useless to someone with little or no vision.\n
This picture is available on their site - ALONG with a text version...\n
The text version is the text that is in the image we first saw.\nAll text was pulled from the picture and put into this alternate form.\nAt the top of the screen shown here is a link to an accessible version of the .png file...\n
Someone else - Chris Throup - made an accessible version of the picture.\nLooks the same.\n
But the code reveals how there is no image in what looked like an image on the previous slide.\nIt&#x2019;s just code - machine-readable code.\n
This slide shows Chris Thorup&#x2019;s code with - at the bottom of the slide - a sample of the WebAIM code for the text version.\nThe same message gets across, but in 2 different ways. The WebAIM sample showed icons echoing the original image.\nHowever, those icons get alt text to tell a person using a screen reader what that icon represents.\n
My point today is doing quality work. That&#x2019;s really what this accessibility stuff is about. Karl Groves wrote a series of blog posts and this quote is the last sentence in the concluding post: \nhttp://www.karlgroves.com/2012/01/27/chasing-the-accessibility-business-case-conclusion/\nRead all the articles in the series and you are well on your way to more accessibility in your work!\n1. Chasing the Web Accessibility Business Case &#x2013; Part 1\n2. Chasing the Web Accessibility Business Case &#x2013; Part 2\n3. The SEO Benefits of Accessibility\n4. Increased Usability Through Accessibility\n5. Accessibility and Reduced Design, Development, Production, Maintenance Costs\n6. Accessibility and Reduced Resource Utilization\n7. The buying power of persons with disabilities\n8. The Social Factors of Accessibility\n9. Support for Low Bandwidth Users\n10. List of Web Accessibility-Related Litigation and Settlements\n11. Website Accessibility Increases Compatibility with Mobile/ Alternative Devices\n12. How Expensive is Web Accessibility?\n13. Accessibility Support for Aging Populations\n14. Reduction of Legal Risk as Accessibility Business Case\n15. Chasing the Accessibility Business Case &#x2013; Conclusion\n
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.\nA screen reader needs similar info because screen reader users need the same thing for navigation.\nARIA 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 http://www.nomensa.com/blog/2010/wai-aria-document-landmark-roles/ \nSkip 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 link on the topic:\nhttp://terrillthompson.com/blog/161\nIt&#x2019;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 users listen to all on-screen text - they can skip around, too, listening to just enough to decide whether to stay or go. Source:&#xA0; http://mattgemmell.com/2010/12/19/accessibility-for-iphone-and-ipad-apps/&#xA0; \nBBC has a standards & 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.\nhttp://www.bbc.co.uk/guidelines/futuremedia/technical/semantic_markup.shtml\n\n\n\n
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&#x2019;t make this mistake!\n\n
Can you do everything with a keyboard? Everything? I use Hootsuite.com for scheduling tweets. I must use a mouse or I cannot complete the login procedure. Same problem with Tweetdeck (which I don&#x2019;t use). 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 they are excluded. I&#x2019;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.\n\n
Use alt text correctly. All the time. For all your images. Period! Read the following links to get things right. Add them to your style guide.\nhttp://dev.w3.org/html5/alt-techniques/ \nhttp://webaim.org/techniques/alttext/ \nhttp://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/\nhttp://yaccessibilityblog.com/library/accessible-image-links.html\n
Labels need to be made correctly. Always identify the form field with an id attribute. \nThen, create a label element for each field. Connect it to the input field&#x2019;s id using the &#x2018;for&#x2019; attribute.\nSource of images: http://www.youtube.com/watch?v=T5OClvFL8I8\nPlaceholder is optional. Read this article for one opinion on why it is a bad idea: http://blog.laurakalbag.com/labels-in-input-fields-arent-such-a-good-idea/&#xA0; \n
In Denmark, it&#x2019;s estimated that 8% men are colorblind and 0.5-1% women are colorblind.\nResource: http://www.sundhedsguiden.dk/da/temaer/alle-temaer/synet/farveblindhed/\nMoral: 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.\nhttp://www.snook.ca/technical/colour_contrast/colour.html\nA keyword is contrast - watch out for color contrast. http://wearecolorblind.com is a great resource about color issues.\n\n
Tables are for data. Make sure your tables are accessible. Because I don&#x2019;t make tables regularly, I forget how to code them properly. 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!\n
You get a gold star if you never do this two things!\n1. DON&#x2019;T USE AUTOPLAY! Hard or impossible to stop using screen reader. If page is opened in a different tab, the sudden noise can be confusing, startling, or conflicting. I.e. cognition issues. DON&#x2019;T DO IT!!\n2. DO NOT USE CLICK HERE OR READ MORE. I rant the reasons why at http://mardahl.dk/2010/11/22/i-dont-want-to-read-more-or-click-here\n\n
Resources for accessible media players. Some are standalone players made to be accessible. The first link is a way to make YouTube accessible.\nThe issue is that screen readers cannot access the controls for the typical media players, which means that 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.\n
Learn more about using screen readers and testing with them.\nA great collection of videos showing screen reader use collected by @dugboticus\nhttp://alistairduggin.co.uk/blog/screenreader-resources/\n\n
When you have coded with accessibility in mind, you need to meet the users. Here are issues you will encounter.\nVisual: blind, low-vision, colorblind (Uncertain how many people have a vision impairment in Denmark. No central register of this data. There are indications that it is around 65 000. \nSource of information: http://www.servicestyrelsen.dk/handicap/synshandicap/om-synshandicap/statistik\nHearing: deaf or hard-of-hearing: about 800 000 people in Denmark have some sort of hearing loss. http://www.hoerehandicap.dk/index.php?id=608\nMotor skills: using mouse, affects control\nCognition: think especially of dyslexia and types of autism, which affects processing of information. I say busy people of average intelligence under stress can also have cognition issues.\nSome US/UK/Canada stats:&#xA0; http://blog.powermapper.com/blog/post/Website-Accessibility-Disability-Statistics.aspx\nThese issues all relate to the terms used in Web Accessibility Content Guidelines (WCAG): P.O.U.R for perceivable, operable, understandable, and robust. \nThe Danish translation of WCAG 2.0 is at http://www.visinfo.dk/wcag20/WCAG20-da.html\n
Users are different. But are you aware of the variety? When you test your systems, test with real people who have real disabilities.\nPersonas can be a substitute in some cases. Personas to help teach accessibility. Developers are more likely to&#xA0; respond if they can see how people can be affected by their inaccessible web pages.\n
This image shows a man named Jennison Ascuncion surfing the web. But his laptop lid is halfway closed. What&#x2019;s he doing? He&#x2019;s listening to his computer via his screen reader. Without vision, he has no use for looking at the screen. (It might be a cool trick to learn to navigate with a screen reader even when not blind. Then you can relieve the boredom of a conference by listening to what you browse on your computer while pretending to listen to the speaker in the room! :))\n\n
This glimpse inside the Yahoo! Accessibility Lab in California shows an example of someone using enlarged text on a monitor. There is a giant red button on a mouse pad &#x2013; it is used by people with motor skill issues. It&#x2019;s easier to hit that big red button than grip and manipulate a little button on a little mouse.\n\n
Here we have a typical kid slaving away at his homework. He&#x2019;s not so typical, however. He has a Braille reader by his side. This cool technology is helping this kid do his homework and use the potential of his brain even though his eyes cannot see. Let&#x2019;s hope all his digital assignments are accessible so he can charge ahead.\n\n
I love this quote from Lisa @scenariogirl Herrod. It says it all.\n
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. Never uninstall the best overall evaluation tool you have &#x2013; your brain!!\nIf testing excites you, consider joining the Browser Testing and Tools Working Group: http://www.w3.org/2011/08/browser-testing-charter.html\n
So what does accessibility cost? The point of this chart is probably familiar to all software developers. It is cheaper to fix things in the early stages and more expensive to fix them in the later stages.\nAll logic says this applies to accessibility, too.\nSource: http://blogs.windriver.com/vxworks/device-management/\n\n
These are all good articles that discuss the cost of accessibility.\nSome argue that the cost is no different from any training you&#x2019;d take to improve your skills. \nThe case study is interesting, but there are too few case studies and there seems to be a need for more case studies. The doubters want proof. Let&#x2019;s start working on collecting the data.\n
WCAG 2.0 is the best starting place for learning about the Web Accessiblity Content Guidelines. They are huge, so this quick guide is handy to remind you of what to consider along the way.\nFrom: http://www.w3.org/WAI/WCAG20/glance/\nW3C WAI http://www.w3.org/WAI/ \n\n
A more detailed starting point to all the WCAG 2.0 literature is the &#x201C;Understanding WCAG 2.0&#x201D;.\nThe quick reference in the second bullet is fantastic. You can specify technologies, success levels, and sections. The techniques and failures are listed for the technologies HTML, CSS, SMIL, client or server-side scripting, Flash, PDF, Silverlight, and WAI-ARIA. Levels are, of course, A, AA, and AAA. Sections are Advisory Techniques or Sufficient Techniques and Failures.\nPS Don&#x2019;t panic. Just take one step at a time.\n
Great coding resources. The Mozilla ARIA resource is huge and growing. Start your ARIA explorations there.\n
Get to know how a screen reader works by reading the first article. \nThe &#x201C;Just Ask&#x201D; link is an online book that is also available in print form. It is also a great way to start your journey into accessibility.\n
The first two links are teaching/teach-yourself resources.\nThe last link is an excellent newsletter that comes out every week. It comes highly recommended.\n
A quick comment on mobile. Mobile accessibility is a topic unto itself. I include these links just as starting points for those eager to learn more in this area.\n
People are probably the best resources. 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. Because the audience today is developers, I tried to pick out the most appropriate Twitter accounts to get everyone started. Note that the last one also has a forum where you can ask all sorts of questions related to developing accessibly.\n
Written by Sandi Wassmer, one of the architects of BS8878 - British Standard akin to Section 508 in the US.\nThese ten principles are in people-speak and another way to get the mindset for building accessibly.\n
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?\n