1 INDATA Web Accessibility Training for Developers Presented

1 INDATA Web Accessibility Training for Developers Presented by Dennis Lembrée December 2014

2 Agenda 1/2 • About @Dennis. L • About You • Intro to Accessibility ▫ Disability & AT ▫ Business Case ▫ Guidelines & Law ▫ POUR • Web Dev Foundations ▫ 4 Layers ▫ Semantics & Order ▫ Other • Techniques ▫ ▫ ▫ Layout/Structure Images/Alt Text Headings Forms Links Keyboard Access Tables Audio & Video About Flash About Validation Java. Script ARIA

3 Agenda 2/2 • Writing • Testing ▫ Checklists ▫ Tools ▫ Manual Techniques ▫ Screen Readers ▫ High contrast mode • • More Tips Resources Contact Details Questions

4 About @Dennis. L • • Author of Easy Chirp. Author of Web Axe. Day job at Pay. Pal e. Bay accessibility team. Presented at CSUN, AHG, HTML 5 Dev Conf, CSS Dev Conf, Access. U. • Presented webinars for EASI and Hadley School for the Blind.

5 About You • Number attending? • How many a developer? A designer? Other? • Years of experience?

6 About Accessibility • • Disability & AT Business Case Guidelines & Law POUR

7 About Accessibility – Disability & AT • Visual ▫ Blindness, low vision, colorblindness • Audio ▫ Deafness, HOH • Motor ▫ Limited ability to use a mouse or keyboard, slow response time, limited fine motor control • Cognitive ▫ Learning disabilities, distractibility, reading level, impaired memory • Neurological ▫ Prone to seizures due to flashing

8 About Accessibility – Disability & AT • Other considerations and situational disabilities: ▫ ▫ ▫ Main language is non-native for user. Broken equipment (mouse, speakers). Temporary disability (hand in cast). Environment (sunlight, library). Low-band connection (unusable with video, bloated Java. Script, multiple images). ▫ Large fingers (need large hit area).

9 About Accessibility – Disability & AT • 2 videos: ▫ Computers and People with Sensory Impairments ▫ Computers and People with Mobility Impairments H ! k r o w e m o

10 About Accessibility – Disability & AT • Assistive Technology (AT) - Visual ▫ ▫ ▫ Eye glasses High-contrast mode Screen magnifier Screen reader Braille output

11 About Accessibility – Disability & AT • Assistive Technology - Audio ▫ Hearing aid ▫ Transcriptions, captions ▫ CART (live transcription)

12 About Accessibility – Disability & AT • Assistive Technology - Motor ▫ ▫ ▫ Alternative keyboard Onscreen keyboard Alternative mouse Switch Mouth stick Head stick

13 About Accessibility – Disability & AT • Assistive Technology - Cognitive ▫ Speech recognition Ex: Dragon Naturally. Speaking ▫ Alternative and Augmentative Communication (AAC) Ex: Proloquo 2 Go ▫ Word prediction ▫ Talking calculators

14 Check on Learning • What are the 5 types of disability? • What are some examples of assistive technology?

15 About Accessibility – Disability & AT • Video demos ▫ JAWS Screen Reader - Hear an Example ▫ How screen readers speak a simple HTML 5 page H ! k r o w e m o

16 About Accessibility – Disability & AT • Simulation exercises: ▫ Take off glasses or wear wrong prescription. ▫ Put rubber band on your off-hand use with mouse. ▫ Wear mittens/gloves. ▫ Set very fast mouse pointer. ▫ Set very high browser zoom. ▫ For multimedia, turn off audio.

17 About Accessibility – Disability & AT • Simulation exercises: ▫ Keyboard only; put away your mouse!

18 About Accessibility – Business Case • Increases potential customer base. • Creates usability benefits for people with and without disabilities, including the increasing aging population. • Reduces development and operational costs (server load, bandwidth, and maintenance). • Improves cross-device browsing, including mobile phones, interactive television, and other delivery channels. (Robust)

19 About Accessibility – Business Case • Avoids possible legal ramifications of not implementing web accessibility. • Creates ocial acceptance; corporate social responsibility. • Eliminates need to provide alternative webpage and media formats (braille, large print, CD, etc). • Case studies, statistic, and figures covering return on investment from web accessibility.

20 About Accessibility – Guidelines & Law • WCAG 1 (1999) • WCAG 2 (2008) ▫ Technology-agnostic. ▫ Warning: already becoming outdated. ▫ Web. AIM’s WCAG 2. 0 Suggestions ▫ Web. AIM's WCAG 2. 0 Checklist

21 About Accessibility – Guidelines & Law • U. S. ▫ Americans with Disabilities Act (ADA) 1990 ▫ Rehabilitation Act Amendments of 1998, Section 508 (part of Rehabilitation Act of 1973) Enforceable in June 2001 Horribly outdated Refresh said to be similar to WCAG 2. 0 AA ▫ Telecommunications Act of 1996 ▫ +Court cases and agreements (Target, Peadpod)

22 About Accessibility – Guidelines & Law • UK ▫ The Disability Discrimination Act 1995 (DDA) ▫ Special Educational Needs and Disability Act 2001 ▫ PAS 78 – guide by British Standards Institution (BSI) & Disability Rights Commission (DRC) • Australia ▫ Disability Discrimination Act 1992 • Canada ▫ Canadian Human Rights Act of 1977 • World policies

23 Check on Learning • What are some business reasons for providing web accessibility? • Is Section 508 up to date?

24 About Accessibility – POUR • Perceivable ▫ Available to the senses (vision and hearing primarily) either through the browser or through assistive technologies (e. g. screen readers, screen enlargers, etc. ) P

25 About Accessibility – POUR • Perceivable ▫ ▫ ▫ P Provide text alternatives for images, etc. Provide captions and transcripts for video and audio. Present content in different ways. Design with proficient color contrast. Avoid movement and distractions on page.

26 About Accessibility – POUR • Operable ▫ Users can interact with all controls and interactive elements using either the mouse, keyboard, or an assistive device. ▫ [Also important for mobile devices!] O

27 About Accessibility – POUR • Operable ▫ ▫ O All functionality is available from the keyboard. Users have control over timing and limits. Do not cause seizures (don’t flash content ~> 3 x per sec). Provide multiple ways to help users navigate, find content, and determine where they are.

28 About Accessibility – POUR • Understandable ▫ Content is clear and limits confusion and ambiguity. U

29 About Accessibility – POUR • Understandable ▫ Economical and plain use of language. ▫ Text supplemented with illustrations, videos, and other formats where appropriate (i. e. , use good Universal Design) ▫ Navigation, information structure are obvious and consistent. ▫ Make pages operate in predictable ways. ▫ Help users avoid and correct mistakes. U

30 About Accessibility – POUR • Robust ▫ A wide range of technologies (including old and new user agents and assistive technologies) can access the content. R

31 About Accessibility – POUR • Robust ▫ Functional across various technologies. ▫ Providing a name, role, and value for non-standard user interface components. ▫ Adhering to W 3 C standards ensures future compatibility ▫ Use semantic markup. ▫ Use progressive enhancement (PE)! ▫ Validate your code - validator. w 3 c. org R

32 Check on Learning • What does POUR stand for?

33 Foundations • 4 Layers • Semantics & Order • Other

34 Foundations – 4 Layers 1. HTML – be POSH! ▫ Plain Ol’ Semantic Html 2. 3. 4. 5. CSS – style Java. Script – to enhance behavior ARIA – accessibility helper CSS for Java. Script? ▫ 5 Layers of Web Accessibility by Dirk @Ginader

35 Foundations – 4 Layers

36 Foundations – Semantics & Order • Semantics ▫ Use HTML element that describes the content (not presentation) ▫ Good for: Accessibility Graceful degradation Future-proofing Easier to maintain (standard, consistency) SEO

37 Foundations – Semantics & Order • Content Order = Source Order = Tab Order

38 Foundations – Other • Strong, em (meaning) vs. b, i (presentation) • Never use an element for its design: ▫ blockquote to indent ▫ headings to bold • Label attribute of select optgroup treated differently in screen readers. • Forms: ▫ If one selection required, use radio, not checkbox. ▫ Avoid multiple-select elements; use checkboxes instead.

39 Check on Learning • What are the 4 layers of accessibility? • Content Order = Source Order = ?

40 Techniques • • Layout/Structure Images/Alt Text Headings Forms Links Keyboard Access Tables • • • Audio & Video About Flash About Validation Java. Script ARIA

41 Techniques – Layout/Structure • Visually consistent ▫ The main areas of the page—such as the banner, navigation, and sidebar—should be in the same place throughout the site. • Consistent markup ▫ The areas should also be marked up consistently, such as using the same heading structure. • Good usability and benefits those with cognitive impairments and those who use AT.

42 Techniques – Images/Alt Text • Provide alternative text for images that have with meaningful content. • Fundamental but complex! • Needed badly on infographics, graphical charts, and comics. Alt text? [Poll]

43 Techniques – Images/Alt Text • If decorative, use alt=“” (but better to use CSS) • If same content exists in page text, use alt=“” • If image linked, alt text should describe purpose of link • Be accurate and succinct. • Don’t use phrases like “image of…” • Avoid text in images • Consider using CSS 3 instead of an image

44 Techniques – Images/Alt Text

45 Techniques – Images/Alt Text • HTML 5 ▫ alt optional with figure/figcaption ▫ aria-describedby vs longdesc ▫ My 2 -part article Longdesc & Other Long Image Description Solutions

46 Techniques – Images/Alt Text <figure> <img src="shadows. jpg" /> <figcaption>Shadow like figures and a graffiti tag drawn on the walls of a partially demolished building, illuminated by the light from a street lamp (photo). </figcaption> </figure> <img src="shadows. jpg" alt="shadow figures" longdesc="description. html" />

47 Techniques – Headings • • • Use one H 1 per page. Brief, succinct text. Nicely nested. Use a heading with <section> element. Wrong: <span style="font-size: 2 em"><b>My Page Title</b></span> • Right: <h 1>My Page Title</h 1>

48 Techniques – Headings

49 Techniques – Forms • Labels • Fieldset/legend • Messages (errors, required information)

50 Techniques – Forms • Labels ▫ All form elements must have a label. ▫ Other methods such as title and placeholder are NOT robust. <label for="firstname">First Name</label> <input name="firstname" id="firstname" type="text" />

51 Techniques – Forms • Fieldset/legend ▫ Great for long forms and radio/checkbox groups. ▫ Screen readers will announce Legend text before each label text within Fieldset. Legend text should be brief & succinct. <fieldset> <legend>Gender</legend> <label for="male">Male</label> <input name="male" id="male" type="text" /> <label for="female">Female</label> <input name="female" id=”female" type="text" /> </fieldset>

52 Techniques – Forms • Alternative method to Fieldset, especially for long Legend text: <p id="question">What is the name of…</p> <div role="radiogroup" aria-labelledby="question"> <input…><label…> </div>

53 Techniques – Forms • Messages ▫ Use aria-describedby for screen readers <label for="address">Address</label> <input name="address" id="address" type="text" aria-describedby="hint. Addr" /> <p id="hint. Addr">Your primary residence. </p>

54 <form action="foo. php" method="post"> <fieldset> <legend>Name</legend> <label for="firstname">First Name</label> <input name="firstname" id="firstname" type="text" /> <label for="lastname">Last Name</label> <input name="lastname" id="lastname" type="text" /> </fieldset> <legend>Location</legend> <p id="hint. Addr">Where you are now. </p> <label for="address">Address</label> <input name="address" id="address" type="text“ ariadescribedby="hint. Addr" /> <label for="city">City</label> <input name="city" id="city" type="text" ariadescribedby="hint" /> </fieldset> </form>

55 Techniques – Forms

56 Techniques – Links • Content (the link text itself) • Awareness • About title/tooltip

57 Techniques – Links • Content (the link text itself) ▫ A link should always have meaning when taken out of context. ▫ A text link should be unique to that page (do not use the same link text for different resources). ▫ Avoid use of "click here", "more", etc. ▫ Do not write out and link a long URL (annoying to screen reader users).

58 Techniques – Links • Awareness ▫ Is this a link? Keep the underline! ▫ Visually indicate when in focus (as well as on hover). ▫ Indicate type of link (if not regular hyperlink, e. g. PDF, MP 4, etc). <a href=“poster. pdf”>Download Poster (PDF)</a>

59

60 Techniques – Links • About title/tooltip ▫ ▫ ▫ ▫ Use for supplementary content only. Assume the user may only sometimes read them. Screen reader users often turn off in settings. No keyboard support (silly browser vendors!) No support on touch/mobile. Use sparingly. DO NOT create redundant titles on links.

61 Techniques – Keyboard Access • Many web users do not use a mouse. • Assistive technologies frequently make use of keyboard input or even a virtual keyboard instead of a mouse or pointing device. • Links and controls cannot require a mouse.

62 Techniques – Keyboard Access • In CSS, use : focus together with : hover a: hover, a: focus { background-color: #ccc; } • Never use: a: focus { outline: none; }

63 Techniques – Keyboard Access • It's always best to stick with the standard A element. • Wrong: <span onclick="window. location='foo. html'; "> foobar</span> • Right: <a href="foo. html">foobar</a>

64 Techniques – Keyboard Access • Avoid general use of tabindex attribute. • tabindex="0" ▫ makes elements besides links and form elements to receive keyboard focus. • tabindex="-1" ▫ makes elements besides links and form elements to receive programmatic focus (by scripting, link, etc. )

65 Techniques – Keyboard Access • Do not use the double-click handler (on. Dbl. Click) • If you use on. Mouse. Over and on. Mouse. Out Java. Script handlers, also use on. Focus and on. Blur. ▫ Not recommended at all, especially considering touch devices.

66 Techniques – Keyboard Access • Interaction patterns: ▫ ▫ ▫ Enter or Spacebar to open widgets. When opening provide feedback to SR user. Up/down arrow keys to select options. Escape to close. Tab closes and focuses next item on page. • Demo: http: //bit. ly/Xbmiwt

67 Techniques – Tables • Provide caption (title of table). • The summary attribute is no longer suggested. ▫ Main purpose, define structure of table, no longer needed. ▫ Obsolete in HTML 5. ▫ Difficult to maintain. ▫ Instead use aria-describedby with P (tabindex="0” required to support all screen readers)

68 Techniques – Tables, cont. • • Use TH for table header cells. Add scope attributes to TH to support older AT. Never nest data tables. Avoid complex data tables if possible. ▫ Use headers and id attributes if necessary.

69 <p id="table. Desc">The following table displays the number of employees and the foundation year of some imaginary companies. </p> <table aria-describedby="table. Desc” tabindex="0"> <caption>Company Data</caption> <tr> <th scope="col" abbr="Company">Company Name</th> <th scope="col" abbr="Employees">Number of Employees</th> <th scope="col" abbr="Founded">Year Founded</th> </tr> <th scope="row">ACME Inc</th> <td>1000</td> <td>1947</td> </tr> <th scope="row">XYZ Corp</th> <td>3000</td> <td>1973</td> </tr> </table>

70 Techniques – Tables, cont. • Video Accessibility: Web Apps: Tables H ! k r o w e m o

71 Techniques – Audio & Video • HTML 5 ▫ Multiple formats required due to differences in browser support. ▫ Ensure controls are accessible. Browser vendors slowing making progress. ▫ Track element for audio descriptions, captioning, subtitles, etc. (low support).

72 Techniques – Audio & Video • HTML 5 <audio> and <video> • Check browser support. ▫ http: //caniuse. com/ ▫ http: //html 5 please. com/ • Check codec support: ▫ http: //mzl. la/Mn 6 tlp (MDN) ▫ http: //bit. ly/Mn 6 wx. N (HTML 5 Doctor)

73 Techniques – Audio & Video • HTML 5 Code <video id="video" width="500" height="300" preload="none" poster="cover. jpg" autoplay="false" > <source src="somevideo. webm" type="video/webm"> <source src="somevideo. mp 4" type="video/mp 4"> <p>Video not supported. You may <a href="foo. mpg">download the MPG here</a>. </p> </video>

74 Techniques – Audio & Video • Transcriptions, captions ▫ Why: Deaf hard-of-hearing language is not user’s native learning-impaired broken speakers in library SEO

75 Techniques – Audio & Video • Transcriptions, captions ▫ Tools: dot. SUB. com Overstream. net Easy You. Tube caption creator MAGpie Captionate (Flash)

76 Techniques – Audio & Video • Transcriptions, captions ▫ Services: Casting Words Even Grounds Dragon Naturally Speaking Volunteers, interns

77 Techniques – Audio & Video • Captioning tips: ▫ Should be accurate, consistent, clear, readable. ▫ Mixed case preferred, but use upper case for emphasis and shouting. ▫ Meaningful sound effects should be included. ▫ Denote when speaker is whispering. [whispering] ▫ When a speaker cannot be identified, user gender to describe (e. g. , “female 1, ” “male narrator”). ▫ For video-only clips, provide a note saying "No sound is used in this clip".

78 Techniques – About Flash • According to screen reader users, Flash content is one of most inaccessible items on the web. • Adobe has worked hard to make it possible to create accessible Flash, but in Windows only! • But in practice, frankly speaking, developers rarely do it.

79 Techniques – About Flash • Use Flash sparingly if at all. • Make every attempt to develop Flash with accessibility. • If it's not possible for whatever reason, be sure to provide alternate content.

80 Techniques – About Flash • A great example of accessible Flash is this entertaining piece by Inclusive Technologies (direct Flash file link): Assistive Technology Boogie. • It's keyboard accessible, provides captioning, and an option for audio description.

81 Techniques – About Validation • Important for interoperability, but don’t go overboard. • Tools ▫ W 3 C Markup Validation Service ▫ HTML Validator for Firefox ▫ Some design/developer applications such as Dreamweaver. • User experience is ultimate test.

82 Techniques – Java. Script • Progressive Enhancement, Unobtrusive • Hijax (Jeremy Keith, 2006) ▫ Develop server-side first. ▫ Then “hijack” and enhance behavior with JS. • Bridge the gaps with ARIA! • Recommended libraries ▫ ▫ ▫ Bootstrap greatly imporoved! YUI 3 (no longer maintained) j. Query Mobile DOJO FLUID

83 Techniques – Java. Script • Manage focus ▫ Essential for accessibility as well as usability. • tabindex ▫ tabindex=0 makes element tabbable ▫ tabindex=-1 makes element tabbable only with Java. Script ▫ Don’t use otherwise.

84 Techniques – Java. Script • Device Independence • Handlers: ▫ If you use the on. Mouse. Over and on. Mouse. Out Java. Script handlers, you must also use on. Focus and on. Blur. ▫ Do not use the double-click handler on. Dbl. Click.

85 Techniques – ARIA • Accessible Rich Internet Applications (WAIARIA) 1. 0 http: //www. w 3. org/TR/wai-aria/ ▫ Roles Widget, Landmark, Document Structure ▫ States and Properties Widget, Live Region, Drag-and-Drop, Relationship • [Poll]

86 Techniques – ARIA • Attributes that define user interface elements to improve the accessibility and interoperability of web content and applications. • If you can use a native HTML element or attribute instead of an ARIA role, state or property, then do so.

87 Techniques – ARIA • ARIA provides not functionality; still must build in with scripting. • Adding an ARIA role overrides the native role semantics. • Tab is not a main navigation tab. • Adding in HTML (landmark, labeling and describing roles) vs. with Java. Script.

88 Techniques – ARIA • • Be careful using role="application" Removes the semantics from the element. Puts AT user in forms mode. Some ARIA elements application role by default (slider, tabs, dialog, toolbar, menu, etc. )

89 Techniques – ARIA • Use role="presentation" to repair parent-child relationships. <div role=“menu”> <ul role=“presentation”> <li role=“menuitem”>Foo</li> <li role=“menuitem”>Bar</li> </ul> </div>

90 Techniques – ARIA • For example, this: <h 1 role="presentation">text</h 1> • becomes this: <>text</>

91 Techniques – ARIA • Example: Menu Button http: //bit. ly/Xbmiwt

92 Techniques – ARIA Live Regions • For AJAX implement Live Regions. ▫ aria-live (property) off, polite, assertive ▫ aria-busy (state) ▫ aria-atomic (property) ▫ aria-relevant (property)

93 Techniques – ARIA Live Regions

94 Techniques – ARIA States • aria-checked (state) ▫ Indicates the current "checked" state of checkboxes, radio buttons, and other widgets. • aria-expanded (state) ▫ Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.

95 Techniques – ARIA Properties • aria-describedby (property) ▫ Like longdesc but on page. • aria-labelledby (property) ▫ Like form label. • aria-required (property) ▫ Like HTML 5 required. • aria-valuemax, aria-valuemin (properties) ▫ Defines the minimum and maximum values for a range widget.

96 Techniques – ARIA & HTML 5 • HTML 5 ▫ ▫ More native power Lighter, semantic code Good support on mobile Exciting • Currently browser and accessibility/AT issues ▫ http: //html 5 accessibility. com/ • Use carefully and with moderate fallbacks.

97 Techniques – ARIA & HTML 5 • No longer temporary. • HTML 5 vs. ARIA • • • required and aria-required menu element vs. menu role longdesc vs. aria-describedby summary vs. aria-describedby structural elements vs. landmark roles (next slide)

98 Techniques – ARIA landmark roles • role = ▫ ▫ ▫ ▫ banner (page header - one per page) navigation (nav) main (main, div - one per page) complementary (aside) search (form, div) contentinfo (page footer - one per page) form, application [rare]

99 Techniques – ARIA landmark roles <header role=“banner”> <nav role=“navigation”> <div role=“main”> <aside role=“complementary”> <form role=“search”> <footer role=“contentinfo”>

100 Techniques – ARIA landmark roles • Video How ARIA landmark roles help screen reader users H ! k r o w e m o

101 Check on Learning • What are the 3 states of a live region? • Name 4 landmark roles

102 Writing • • Use short sentences. Use short paragraphs. Favor the active voice over passive voice. Do not use jargon, slang or idiomatic phrases.

103 Writing, cont. • Avoid directional language. ▫ “In the links to the left…” • Don’t convey meaning with color alone. ▫ “Click the green button to…”

104 Writing, cont. • Provide definitions of technical terms. • Provide full terms for lesser known acronyms and abbreviations ▫ Write full text at least once on page. ▫ Use abbr element; acronym deprecated. <p>I leased a new <abbr title=“Volkswagen”>VW</abbr>. </p>

105 Writing, cont. • Page title (descriptive, concise, unique) • Headings (descriptive, concise, unique) • Descriptive link text (meaningful on own)

106 Writing, cont. • Alternative text ▫ Decorative? Linked? Already on page? • Legends and Labels (brief and succinct) • Define language (page level and inline) ▫ <html lang=“en-us”>

107 Check on Learning • Is it better to use the abbr or acronym element?

108 Testing • Use multiple avenues to test • Checklists • Toolbars • Manual techniques • Screen readers • High-contrast mode

109 Testing - Checklists • Useful or not? • Examples: ▫ Web. AIM’s WCAG 2 checklist ▫ Section 508 ▫ Internal

110 Testing - Tools • Toolbars are useful for everyone. • Examples: ▫ ▫ ▫ WAVE (by Web. AIM) WAT (IE, Opera by TPC) Web Developer Toolbar (Firefox, Chrome) Accessibility Inspector for Firebug Fire. Eyes for Firebug

111 Testing - Tools • Automated testing is great for “easy” catches and large projects. • Alone catches only ~25% of issues. • Examples: ▫ ▫ Tenon. io (w/Node. js) Deque Fire. Eyes (w/Firebug) Quail. JS. org WAVE (by Web. AIM)

112 Testing - Manual Techniques • View code to ensure: ▫ Doc type set ▫ Language definition set ▫ Similar text between page title and H 1 • • • Text zoom (150 vs 200%) Keyboard only Turn off Java. Script Turn off CSS Adequate text size

113 Testing - Manual Techniques • • Layout Not using color alone to convey meaning Check doc structure Check on different browsers and screen sizes Check on different devices Text-only browser such as Lynx Reading level

114 Testing - Screen Readers • NVDA ▫ NVDA tutorial • JAWS • Voice. Over (OS X, i. OS) • Talk. Back (Android) • Fangs ▫ Firefox add-on which simulates screen reader output with text output. • Window-Eyes free to users of Microsoft Office

115 Testing - High-contrast mode • Quick to do! • In last Web. AIM SR survey, 8. 5% of SR users also use high-contrast mode or custom style sheets. • On Windows, background images won’t appear. • Windows shortcut: left SHIFT + left ALT + PRINT SCREEN

116 Check on Learning • Do you think checklists are useful? • What are some good toolbars/automated tools?

117 More Tips • Focus is your friend! (Great for both keyboardonly and screen reader users) • Plan accessibility from the very start. ▫ Wireframes • Small file sizes (lowband, mobile). ▫ ▫ Compress images Use external JS, CSS (and minify) Remove duplicate code Minimize HTTP Requests, use CDN

118 More Tips, cont. • • NVDA and Voice. Over screen readers are free. Screen readers use Java. Script. Error handling is very important. Warn user when linking externally to anything other than an HTML page. ▫ Use role=“button” for Anchors with button-type functionality.

119 Resources • Companies: ▫ Web. AIM, Yahoo, IBM, Adobe, The Paciello Group, Knowbility, Pay. Pal • People: too many to name, check Twitter! ▫ Hash tags such as #a 11 y ▫ Twitter lists • Not a tweep? Try: Facebook. com/Web. Axe • You. Tube channels ▫ DO-IT ▫ We Are Nomensa

120 Resources, cont. • W 3 C WAI (Web Accessibility Initiative) ▫ WCAG 2. 0 ▫ WAI Handouts and WAI Flyer ▫ Lots more! • Email newsletters ▫ Web. AIM, Linked. In Groups, etc. • Books, Articles ▫ Pro HTML 5 Accessibility (review) ▫ 25 Ways To Make Your Site More Accessible

121 Contact Details • Websites ▫ Easy. Chirp. com ▫ Web. Axe. org ▫ Dennis. Lembree. com • Twitter Accounts ▫ @Easy. Chirp ▫ @Web. Axe ▫ @Dennis. L

122 Questions?