This a presentation prepared for a Montana Web Developer's Meetup in December, 2011. The focus is on collaborating with content providers and employers to share the responsibility for web accessibility.
Who am I? - A web designer and programmer - An advocate for web accessibility - A writer on practical accessibility
What am I going to talk about? 1) Overview of web accessibility 2) Collaboration between developers and creators. 3) Tips to find obvious accessibility flaws 4) Tools and resources for further work.
Web Content Accessibility Guidelines v.2 Principles: - P erceivable - O perable - U nderstandable - R obust
Technology independent & Accessibility Supported - Guidelines are based on principles, not technology - Guidelines require techniques be accessibility supported to be considered accessible What the heck is “accessibility supported” supposed to mean?
Can assistive technology see your data? - If assistive technology tools, such as screen readers, can retrieve the information you've placed on the page. - Combines multiple facets: - Developer provides information on the page - Browser reads it and communicates to the OS - OS passes information to assistive technology
All browsing tools are assistive technology - Tools which translate raw data into a mode you can perceive, whether that mode is - Visual, - Aural, or - Tactile. - Standard browsers assume the ability to see, hear, and operate controls.
Accessibility is collaborative - Client: - generates content - guides shape of the overall site - Designer: - colors - fonts - layout - Developer: - structure - metadata - error management
Outline Structure Treats entire page (not just content) as an outlined document - Content creator : how do the parts (navigation, sidebars, header, footer, content) relate to each other? - Designer : Each section needs a heading; and this works into the design as structure - Developer : Uses information to provide a heading structure that assistive tech uses as navigational tool.
Reading Order - What order should the page be read in? - Independently, what order should the content be read in? - Content creator : complex articles include captioned images, diagrams, asides, and footnotes. When should this items be read? - Designer/Developer : Uses the above information to place content in a linear order for assistive technology
Font Selection Choose fonts which allow true text usage and which are easily readable - Content creator/Designer : Understand that your choices need to be limited; use standard web fonts or fonts licensed for web embedding. - Developer : Avoid font replacement techniques with poor accessibility: Cufon, sIFR, or image replacement. True text is faster, cheaper, and more flexible, as well!
Preparing Content Write content with linking text and outline structure in mind; use the simplest language appropriate to the topic. - Content creator : Will your audience understand this text? Do links use natural language and clearly define their targets? Is an article broken into discrete, scannable chunks? - Designer / Developer : Should be thinking about these issues while laying out content, and point out issues needing re-writes as they go.
Video. Audio. Animation. Require the most complex accessibility implementations. - Content creator : Provide transcripts, avoid strobing content – plan ahead so that developers have enough time - Designer/Developer : Implement captions, audio descriptions. Don't auto-start; make sure controls are keyboard accessible.
Testing doesn't always need special tools - Understanding how disabilities use a site - Learning how to see potential problems - Applying the principles of accessibility support
Think like assistive technology - Imaging you were blind isn't sufficient; you also have to think like a machine - You have to understand what information is available to the computer. This form of testing is only an overview: it can't detect every problem. It can forestall endemic issues, however.
The Blind Experience - Is keyboard dependent. - Uses complex keyboard commands - Gets information about visual objects from related text Can links be visited via keyboard? Form fields? Submit buttons? Are form responses announced when a form is submitted? Has the web site defined keyboard controls which may conflict with the assistive technology? Do images and videos have text equivalents?
Low vision or partial sight. - Use OS tools or assistive technology with screen magnification - May adjust browser settings to increase font size - May use alternate contrast schemes - May have narrow field of vision Is all text visible when the font size is enlarged? Are line lengths to long for lines to be followed using screen magnifiers? Is contrast sufficient for text to be legible with poor light perception or color blindness? Do instructions depend on color identification for success?
Reduced fine motor skills. - May use a mouse, but have difficulty controlling it with precision. - May be keyboard dependent. - May use special pointing devices such as a mouth stick, head wand, or eye tracker. Are clickable areas large enough to activate using less refined pointing devices such as a mouth stick or head wand? Is keyboard focus visible, so keyboard dependent users can tell what they are currently activating?
Cognitive Limitations. - May need extra time to complete time-based tasks. - May become confused if navigation or layout of site changes significantly from page to page - May need orientation tools to return to previous pages - May be highly distracted by motion or sound Concerns relating to learning disabilities range broadly across issues with recall, comprehension, reading skill, attention, and spatial cognition. Use of contrast, color coordination of related items, choice of fonts, and simplification of written text are among the rich variety of strategies for supporting these issues.
Overview of testing. The best testing is to put a group of assistive tech users in front of your site, and set them tasks to accomplish. This is, obviously, beyond the means of most developers and clients. The compromise is threefold: - Limit use of newer, less-tested technologies. - Keep up with those who are doing full-scale testing. - Research new features thoroughly.
General purpose tools (free!). - Firefox Accessibility Toolbar: http://bit.ly/firefox-toolbar - Internet Explorer Accessibility Toolbar: http://bit.ly/ie-toolbar - WebAIM's WAVE tester: http://wave.webaim.org - Windows 'Ease of Access': http://bit.ly/ease-of-access - MacOS Accessibility: http://bit.ly/mac-access
Finding more information. - WCAG Recommended Techniques : highly technical, though simpler than the WCAG itself. http://www.w3.org/TR/WCAG-TECHS/ - WebAIM: Simplified summaries, recommendations. Extensive documentation on almost every accessibility topic: http://webaim.org - University of Minnesota, Duluth Web Design References: Extensive curated catalog of accessibility articles on the web: http://bit.ly/t3tPZC