Accessibility - More than just ALT Text

This session will give you not only a brief overview of what accessibility on a website means, but also some working examples of HTML coding and other techniques that will fix some of the most common issues. Examples will be provided on forms, document structure, color contrasts, tables, images, video, pdf’s and more. If you are overwhelmed by the standards websites on WCAG and section 508 guidelines, this session will give a summary of those and provide you with resources, both free and in the marketplace, for detecting and fixing issues on your own website. Through a recent ground-up redesign of her university’s website, Mandy and the web team have learned a lot about accessibility and continue to try to understand this complex field and make adjustments to better serve all audiences. She will share what they have learned.

Transcript

1. It’s more than just ALT Text HEWeb‐West Conference June 3, 2013 Mandy Thomas Webmaster Chapman University
2. Making web pages usable by everyone, regardless of abilities and inabilities
3. Part of modern life • Web is increasingly an essential resource for much of life: • education • employment • government • commerce • health care • recreation • social interaction • The Web is used not only for receiving information, but also for providing information and interacting with society
4. The Goal For disabled users to be accomodated without decreasing the usability of the site for non‐disabled users.
5. Game Changer • The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, physical or mental ability. • When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability. • Therefore “disability” is radically changed on the Web because it removes barriers to communication and interaction that many people face in the physical world. • However…
6. When websites are designed without accessibility in mind they can create barriers that exclude people from using the Web.
7. Types to Consider • Visual: impairments including blindness, poor eyesight, and color blindness; • Motor/Mobility: difficulty or inability to use the hands (including tremors, muscle slowness, loss of fine muscle control); • Auditory: deafness or hearing impairments; • Seizures: caused by visual strobe or flashing effects; • Cognitive/Intellectual: developmental or learning disabilities (dyslexia, dyscalculia, etc.), and cognitive disabilities of various origins, affecting memory, attention, developmental "maturity," problem‐solving and logic skills, etc
8. But did you also know… • Accessibility supports social inclusion for some groups of people you may not have thought of: • older people • people in rural areas • people with a short‐term injury or illness • people in developing countries • people with low literacy • people using older equipment or technologies
9. • Older users may require more time to complete a form, or have poor eye sight and not be able to read small fonts • Users in rural areas may have such a slow connection to the internet that they disable images in their browser, relying solely on the text and links remaining on the page • Users with temporary conditions such as a broken arm may not be able to use a mouse
10. Assistive Technologies • Users who have permanent disabilities may not be using the typical visual browser such as Firefox or Chrome • They may use other assistive technologies
11. JAWS • Blind users may use use browsers such as JAWS • JAWS = Job Access With Speech • A computer screen reader program for Microsoft Windows • Allows blind and visually impaired users to read the screen • either with a text‐to‐speech output, or • by a refreshable Braille display
12. Non‐Visual Issues • Users with hearing disabilities may need alternative formats such as: • transcripts for content that is in audio • Captions in content that is in video format Highly recommend viewing “How people with various disabilities use the web”: http://www.w3.org/WAI/intro/people‐use‐web/Overview.html
13. The Bottom Line There is also a strong business case for accessibility Case studies show that accessible websites have: • better search results • reduced maintenance costs • increased audience reach • lower chance of lawsuits • http://www.w3.org/WAI/bcase/Overview
14. Not Starting Over • You may already doing a lot of the right things • Accessibility overlaps with other best practices: • mobile web design • search engine optimization (SEO) • usability • writing valid, well‐formatted, modern HTML and CSS
15. Definitions • W3C (World Wide Web Consortium) • An international community that develops open standards to ensure the long‐term growth of the Web • WAI (Web Accessibility Initiative) • An initiative within W3C whose mission is to lead the Web to its full potential to be accessible, enabling people with disabilities to participate equally on the Web. The group consists of industry representatives, accessibility consultants, universities, and accessibility experts. • WCAG (Web Content Accessibility Guidelines) • The document created by the WAI with their recommendations on website design for accessibility. WCAG 2.0 is current version.
16. More about WCAG 2.0 • WCAG 2.0 has 3 main priority levels to measure against • Level A: • Web developers must satisfy these requirements, otherwise it will be impossible for one or more groups to access the Web content. • Level AA: • Web developers should satisfy these requirements, otherwise some groups will find it difficult to access the Web content. • Level AAA: • Web developers may satisfy these requirements, in order to make it easier for some groups to access the Web content. • http://www.w3.org/TR/WCAG20/ for full guidelines including techniques and tests to measure success in compliance
17. Government • Section 508 • refers to a government document • part of the Rehabilitation Act Amendments • “requires that individuals with disabilities, who are members of the public seeking information or services from a US Federal agency, have access to and use of information and data that is comparable to that provided to those who are not individuals with disabilities” • WCAG is not the same as Section 508 but the two are similar and often WCAG guidelines are used to check Section 508 compliance • State governments may have their own similar but varying requirements – some of which are legal mandates for state colleges and universities
18. The Basics Some specific characteristics of an accessible site include: • clear and logical navigation; • easy to read and understandable links; • text descriptions of essential visual elements; • transcripts or captions for audio, video etc. • interoperability with assistive technology And now for some practical examples of the HTML…
19. Alternate Text for Images • Provide alternate text describing graphic images. It’s converted to auditory or tactile output for user. <img src=“apply-now.gif” alt=“button to apply for admission”/> • Helps user determine if function of image is for presentation purposes or functional purposes • Purely decorative images don’t need alternate text but must still provide an empty ALT attribute <img src=“banner.gif” alt=“”/> • Caveat: empty ALT attritubes will still fail some Accessibility reporting/testing software so may want to provide anyway • Best practice for purely decorative images is to use CSS (not in content)
20. H1 Heading tags • One, and only one, H1 heading tag per page • Should clearly convey page content • Screen reader can skip to H1 and avoid main menu <h1>Graduate Admission</h1>
21. H2‐H6 Heading Tags • Should be in order and properly nested • Convey page’s organization • Screen readers produce a list of headings on a page, from which the user can jump around page • Don’t use heading levels for their default size—use CSS to style your headings • http://www.youtube.com/watch?v=AmUPhEVWu_E (video of how a screen reader uses headings)
22. Example of nested headings HTML source Display in browser
23. Other uses for headings • In collapsible regions or tabbed containers, headings should be H2 or H3
24. Skip‐navigation links • Skip‐navigation links are not just for screen reader users • Allows those who cannot use a mouse to circumvent cumbersome navigation menus and side bars • Someone relying on keyboard navigation will usually have to tab through ALL of the navigation items to reach the main content on the page. • Can be visible or invisible on page • Not everyone agrees on best solution • Ideas found on http://webaim.org/techniques/skipnav/
25. Acronyms • Avoid using acronyms when possible • If used, enclose them in ABBR tag and provide full name
26. Links • Link useful text not “Click Here” • Don’t display url, display description of webpage linking to • Don’t open links in new window or tab • Don’t repeat the same link text multiple times on the same page e.g. a series of articles and each one has “Read More” link at the end
27. Font Color • Users with color blindness may not be able to differentiate links from plain text solely on the basis of text color. Underlining helps and is commonly understood • Users with low vision may not be able to differentiate text from background color if contrast is insufficient • The smaller the font the higher contrast is required
28. Contrast • WCAG AA requires a contrast ratio of • 4.5:1 for normal text • 3:1 for large text • WCAG AAA requires a contrast ratio of • 7:1 for normal text • 4.5:1 for large text • WebAIM has a color contrast checker • Colorzilla and Juicy Studio Accessibility Toolbar are additional tools for extracting the color value from any page element
29. WebAIM Color Contrast Checker • http://webaim.org/resources/contrastchecker/ • Can test or choose 2 colors that pass contrast ratios
30. Forms • Use label tag, plus the ID attribute in input field, to pair visible, descriptive text with the form field • Screen reader will read out text between labels when the input field gets focus • Label’s “for” and input field’s “id” must match exactly. They are case‐sensitive
31. Text, Textarea, and Select fields
32. Checkboxes and Radio Buttons • Set of all options must be surrounded by fieldset tags • Need legend tag for the visible field label • Need unique label tag for each choice • Unlike text boxes, labels are after the field, not before
33. Label Placement • The visible labels for form fields can be: • Left of input field • Left of input field but right justified • Above the input field • Placing the label above the field reduces eye movement and processing time by the brain ‐‐ making it easier for user • Bolding the labels can visually separate from fields but also takes more eye movement and brain processing http://www.uxmatters.com/mt/archives/2006/07/label‐ placement‐in‐forms.php
34. Required Fields • If the form has both required and optional fields, add the aria‐required="true“ attribute to required fields • This will identify that it may not be left blank to screen reader
35. Sections on Forms • Use HR tag or heading tags to separate or associate sections of related content on form
36. Tables • Identify headers with TH tag • Include scope attribute to associate the header with either a column or row • If the first column is the key to the rest of the data on that row, make it TH as well
37. Table ‐ Summary attribute • Provide SUMMARY attribute in the table tag • This is invisible text describing table to screen readers • Goes over of the purpose and/or explains how to navigate the information in the table
38. Tables and Screen Readers • Screen readers will read out the caption and summary information for the table • As users move to left or right along a data row, they will hear the column header followed by the information in current cell
39. Table – Caption tag • If want a heading above the table use the CAPTION tag • This associates the heading with the table for screen readers • If table has both summary and caption, they should not be duplicate information • Captions are visible, Summary is not
40. Tables for layout • Using tables simply for layout (to align or position text or images) is not recommended • However it does not violate WCAG guidelines • Using CSS to layout content on your page is preferred • If you do use tables for layout, do not identify header rows (use only TD not TH) and do not include scope or summary or caption elements
41. More Complex Tables • Tables with column headers and subheaders require use of id and headers attributes to associate data with each applicable header • Add a unique id to each TH header tag • Add headers attribute to each TD tag and list all associated header IDs in the order you want them to be read out • Sample Table:
42. Table with multiple headers
43. Add ARIA Landmarks • Identify and give meaning to specific parts of your page • Makes them more keyboard navigable. • http://webaim.org/techniques/aria/#structure for complete list. • Add role=“main” to div that surrounds the main body of content on your page; or if using HTML5 add it to the <main> tag • Add role=“navigation” to div that surrounds your main navigation on the page; or if using HTML5 add it to the <nav> tag • Add role=“search” to either the div surrounding your search form or to the form tag itself
44. Beyond your webpages An accessible Web site includes the accessibility of all its content, not just webpages. This includes Word and PDF documents, graphics, forms, audio and video.
45. Tagged Documents • PDFs and Word documents linked from your website should also be accessible • Microsoft Word provides ability to use headings just like html to provide structure to content: • Word converted to PDF will retain tagging • Adobe Acrobat Professional is required to evaluate, repair, and enhance the accessibility of existing PDF files • Useful resource: http://webaim.org/techniques/acrobat/acrobat
46. Alternate Text in PDFs • Word provides ability to add Alt Text to images in the Word document. • Right‐mouse click on image, choose Format Picture, choose Alternate Text tab
47. Audio and Video • Provide a transcript as a text alternative to audio linked from your site • Add captions to video, or provide script alternative • Many free video captioning tools available • “Description” is in addition to caption. It’s narration that translates images and other visual information into spoken words. Typically inserted into pauses between dialogue • http://www.uiaccess.com/transcripts/transcript_services.html #ae – list of transcription services
48. Video Captions • This list of Captioning Tools from George Mason University’s website: • Free Captioning Tools • MAGpie • Subtitle Workshop • World Caption (Mac) • CapScribe (Mac) • dotSub • CaptionTube ‐ Target Center training video for captioning YouTube Videos • Overstream • vSync Bookmarklet • Easy YouTube Caption Creator • • Captioning Tools (at Cost) • DocSoft (Mason has free to use) • Dragon Naturally Speaking (Free to use at Mason campus') • Captionate (For Flash) • AutomaticSync • MovCaptioner (Mac)
49. Many More Resources • http://www.w3.org/TR/WCAG20/ WCAG 2.0 guidelines and testing criteria • http://webaim.org/blog/10‐easy‐accessibility‐tips/ A blog on 10 simple things you can do now to improve accessibility on your pages • http://www.washington.edu/accesscomputing/tips/ 30 Accessibility Tips by Terrill Thompson, Technology Accessibility Specialist at UW • http://www.calstate.edu/accessibility/webaccessibility/ California State colleges accessibility guidelines and tools
50. Many Tools • The following are tools to help you with accessibility • http://www.w3.org/WAI/ER/tools/complete ‐ list of tools to evaluate pages or whole site • browser toolbar add‐ons which assess any element on the current webpage: • http://wave.webaim.org/toolbar/ for Chrome • https://addons.mozilla.org/en‐us/firefox/addon/wave‐toolbar/ for Firefox
51. The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect. ~ Tim Berners‐Lee, W3C Director