What is accessible Web design?

A Web Site is accessible when it can be understood by everyone, regardless of what browser or adaptive equipment he or she may be using. Creating a new Web site that is accessible, or making your current Web site accessible, is easy and benefits everybody.

This seminar was created to help Penn State Web developers and faculty develop, adjust, or adapt Web based course materials so that they are accessible, and to raise both faculty and staff's awareness of disability issues as they affect teaching and learning with technology.

Assistive Technology Labs

Seminar Page 3

These are a few locations at University Park where students with disabilities can access specialized computer terminals and other equipment.

• Library Services for Persons with Disabilities - Includes a wide range of assistive technology options
• Assistive Technology in Student Computing Labs
• Boucke 115 - This facility is only available to students who are registered with the Office of Disability Services.

Penn State Policy AD-54 and Section 508

Seminar Page 4

The most current information on Penn State Accessibility policy is available from Access P.S.U.

The Penn State Policy AD-54 "Web Page Design and Image" has been revised to require accessibility accommodations in Penn State Web sites matching this Section 508 guidelines (New Window) mandated for federal government Web sites.

AD-54 Policy and Accessibility

To quote from policy AD-54:

• Web Markup Standards: Site administrators should integrate W3C and Section 508 standards into site planning and design.
  
• Accessibility: The University's policy is to be compliant with Section 508 of the Rehabilitation Act Amendments of 1998.
  
  • New Web pages and sites should comply, to the extent possible allowed by current technology, with Section 508 of the Rehabilitation Act Amendments of 1998, the Web-based intranet and Internet information and applications (1194.22) http://www.section508.gov/index.cfm?FuseAction=content&ID=12. Current pages and sites should be evaluated and developers should implement a timely program to address major flaws, using current best practices and professional judgment.

References to Section 508 Guidelines will be mentioned when relevant to discussing different HTML tags and tools.

NOTE: The LIFT Dreamweaver plug-in available from the Penn State Computer Store can check a Web site in terms of compliance with Section 508.

WCAG Guidelines and Other Guidelines

Although Penn State has elected to require compliance with Section 508 guidelines for official Penn State Web pages, you should be aware that other guidelines have been developed, some with more or different provisions.

WCAG

The other major guideline cited by usability experts is the Web Content Accessibility Guidelines ( WCAG) which is now being upgraded to WCAG 2 to include options for Web 2.0 applications and upgraded guidelines. The revised version of Section 508 (also pending) may parallel WCAG 2.0 guidelines more.

The guidelines for both WCAG 1 and WCAG 2 are divided into three priority levels, with Level 1 being the most critical guidelines and Level 3 the least critical.

WAI-ARIA

Another standard is WAI-ARIA which is a set of guidelines just for dynamic Web pages and Web applications. The very latest browsers (Firedox 3, Internet Explorer 8, Safari 4) can now recognize WAI-ARIA tags.

Other Guidelines

In addition, many countries are implementing their own national guidelines. If your Web site is housed in or substantially interacting with a particular nation, you may want to check their guidelines in addition to Section 508 guidelines.

Finally, individual colleges, departments or units may require additional accessibility guidelines.

Other Penn State Web Site Requirements

See the Penn State Web Style Guide for details on other Web Page guidelines such as logo placement, specifying contact information and implementing a standard Search function.

Top of Page

Different Standards for Different Purposes

Seminar Page 5

Although accessibility is related to the issues of usability and coding standards, it is possible for a site to be considered usable and standards compliant but NOT accessible (and vice-versa). Below are some definitions and situations where distinctions may arise.

Usability

Usability refers to the ability of average users with the "standard" range of equipment or abilities to navigate and use a Web site. In most cases, accessibility standards will also add usability to a Web site, but accessibility consists of more than just usability.

Web Standards

Web standards refer to initiative from the W3C Consortium and other Internet standards bodies to develop open Web standards which can be used by any software developer. The goals of standards is to ensure cross-platform compatibility and more compact file sizes.

The focus of standards has been to separate "content" from "formatting" by implementing CSS styles. Although CSS can definitely facilitate accessibility, it is possible to design inaccessible styles. Similarly, a non-CSS solution could be as equally accessible as a CSS solution.

A Standards Compliant site does not guarantee an accessible site.

Potential Mismatches

Although many accessibility guidelines are straightforward, some guidelines may conflict with usability or standards. For these cases, extra care must be taken to ensure that all audiences are able to access and use a Web site.

When Usability, Standards and Accessibility Collide

Issue	Good Usability/Standards	Bad Accessibility	Solution
Color Coding	Color is a key visual signaling device for humans	BUT, about 10% of men are partially color blind and cannot distinguish certain colors (especially red/green)	Supplement color coding with text/icon coding
Acronyms & Compounds	Style conventions may require acronymns like HTML, PDF, NaCl, Sitemap, etc. to be listed without periods or spelled as one word	BUT, screen readers often mispronounce these items.	Include the ACRONYM tag to assist in pronunciation
Multimedia	Using images, sound and animations can often be more comprehensible than large blocks of text. Some people even recommend icons for users with some cognitive impairments.	BUT screen readers cannot interpret multimedia elements without textual assistance	Always implement ALT text, extended text descriptions and captioning or transcripts
Repetitive Navigation	Having navigation repeated on top and bottom is good for consistency and for some motion disorders.	BUT it is tedious for users of screen readers to hear the navigation on every page.	Implement "Skip Navigation" strategy
Multiple Columns	Multiple columns are one way to reduce text width to narrower widths conducive for legibility and include more material in one screen	BUT multiple columns are difficult for some screen readers to interpret.	You can use style sheets to reduce a column width within a single-column layout. Use appropriate table tags for data tables and make sure layout tables make sense when read left to right, top to bottom.
Unicode for Foreign Languages	Unicode makes data exchange between operating systems and foreign languages easier.	BUT some screen readers cannot recognize Unicode input.	Consult with users for best solutions. Symbol or Audio files may be needed for some items.
PDF Files	PDF may be the only way to present information in complicated layouts or with unusual symbols online for all browsers.	Screen readers may not be able to interpret all the information	PDF files need to be made accessible just as Web pages are.

Top of Page

Some Accessibility Gotchas

Seminar Page 6

There has been a lot of discussion of accessibility over the years and some implementation myths have sprung up.

1. There's only a small audience for accessibility

Myth - Accessibility compliance only benefits users registered with the Office of Disability Services.

Reality - At some point almost all of us will be in a situation where 1) the image link is broken, 2) the colors are not distinguishable, 3) the text is too small 4) the audio is not working, 5) we cannot see the whole screen or 6) we cannot move the mouse properly.

2. Accessibility = Captioning

Myth - If we caption all our video and audio recordings, we are accessible.

Reality - Accessibility also includes accomodations for users who are visually impaired, mobility impaired, and many other users with slighter impairments or lower-quality technology options.

Note - In the past accessibility was equated to just implementing image ALT tags. The rise of podcasting and video brought awareness of captioning needs to the surface.

3. If it's Audio, then a Screen Reader can access it

Myth - If content is delivered by audio, then by default a visually impaired user can access it.

Reality - The navigation to the audio (including the login) may not be accessible.

4. CSS Styling will Guarantee Accessibility

Myth - If I use CSS stylesheets, I will guarantee that my site will be accessible.

Reality - Although CSS stylesheets can improve accessibility, you can also create additional accessibility issues if you use the markup incorrectly. Similarly you can create sites which are standards compliant but still inaccessible. Section 508 does not require CSS, but Section 508 does require sites to be usable without CSS stylesheets.

The same statement applies to other standards such as XHTML, XML, MathML, Unicode and other standards. These standards facilitate data exchange and are easier for accessibility tools to work with, but do not guarantee accessibility.

5. Text Only is a good accessibility option

Myth - Creating a parallel text-only site while maintaining an inaccessible site as is the best solution for accessibility.

Reality - Most users prefer that accessibility options be incorporated into a single Web site, saving text only transcripts for multimedia and plug-ins as needed. The reasons include.

1. Many people with disabilities feel that text-only sites are exclusionary. A single site with appropriate accessibility is perceived as more inclusive to the entire Internet community.
2. It's much more difficult to maintain a second site. Once it's out of date, you are out of compliance because equivalent information is not available to everyone.
3. Modern screen readers can actually process accessible HTML better than a text-only site.
4. Text-only sites may address some accessibility issues specific to screen readers, but not all accessibility issues.
5. Accessibility goes beyond "text only," so the original site must be reviewed in any case.

Note - Using CSS style sheets to present alternate views of content may be a valuable toolin some situations.

6. Accessibility Requires EM and STRONG

Myth - You must replace the B (bold face) and I (italics) tags with STRONG and EM tags to be compliant.

Reality - The STRONG and EM tags are functionally different from B and I in that screen readers change reading styles to highlight important information. However many uses of bold face and italics are for visual formatting only and may be irrelevant to screen readers. Use of STRONG and EM is not required by Section 508.

7. Accessibility Means No More Tables, JavaScript, Flash, Image Maps or Frames

Myth - All HTML tables, JavaScript, image maps, multimedia and frames must be removed to be compliant.

Reality - None of this is required by Section 508. What is required is that that these tools be implemented with sufficient information for a screen reader to use. In most cases, this only requires the addition of specific attributes. Even JavaScript programmers have developed techniques to create accessible code, especially in terms of ARIA.

8. Accessible Design is Plain

Myth - An accessible Web site is a plain Web site.

Reality - More complex designs can be accomplished and still be accessible. They key is to incorporate elements which do not interfere with readability, motion impairment or screen reader access. See the Web sites for Access P.S.U. and the Office of Disability Services for examples. Not to mention WebAim, Jim Thatcher Accessibility Tutorials, Accessify Com and many others.

9. Minimum 508 Compliance is Perfect

Myth - If you meet the minimum for Section 508 compliance, you will never have to worry about accessibility issues again.

Reality - Not all accessibility issues are covered in Section 508 regulations. Further, advances in Internet options will inevitably create additional accessibility issues. This page and this site will no doubt need to be redesigned in the coming years, although hopefully not too drastically.

10. Waiting for problems is just as easy as doing it now

Myth - You don't need to worry about implementing accessibility until a user requests accommodation.

Reality - If "an ounce of prevention is worth a pound of cure," then one minute of implementing an extra tag or adding more descriptions is worth one hour of finding each problem and figuring out how to fix it. Retrofitting a site for accessibility is far more time consuming than implementing it from scratch.

Seminar Page 8

Here are some tips for effectively understanding and implementing accessibility strategies.

1. Experience a Screen Reader, a Film with no Audio and so forth

There is no wake up call like viewing a Web page you have developed on a screen reader to understand the issues that visually impaired users might face. This is also true for using the Internet with a grayscale monitor, a small screen, no audio, slow bandwidth connection or other less than ideal conditions.

2. Use a Multi-Pronged Testing Strategy

A testing strategy should include a standards verification report, checking to see how the site appears with images and CSS disabled, a color contrast check and an audit of content with

In addition any plugins, applications and web apps should be checked to ensure that they work with a screen reader (including login and navigation). Even if the plugin itself cannot be used, it may be possible to present the content or function within an alternate tool/format.

3. Remember the Context

There are very few accessibility requirements which can be blindly applied without considering the context of the Web page. For a screen reader audience in particular, a balance between too little information and too much redundancy should be maintained.

4. Make Sure Accessibility Tags or Tools are Supported

Some of the newer accessibility tags and standards have been proposed, but do not have full support yet in screen readers or broswers. Before spending great time and effort implementing new tags, make sure that modern browsers and screen readers such as Jaws have implemented them recently. Otherwise, it may be more efficient to use some other accessibility strategy.

For instance screen readers may not support all the tags for complex tables. In that case, a series of simple tables may be more accessible to more users.

5. Be Patient with Developers

Some tags and recommendations are time consuming to implement, especially if a Web site needs to be retro-fitted for accessibility. However, having developers experience screen readers may give them a different perspective.

6. Be Patient with Accessibility Experts

Accessibility is, unfortunately, a complex issue which does not always lend itself to simple answers. You may hear conflicting advice on how to best implement accessibility. Understanding the audience issues and your goals will hopefully provide you with sensible alternatives.

7. Be Patient with Users

Evan after implementing all the recommended tags and strategies, some users may still encounter problems you were not aware of, either because of unique conditions or outdated browsers or equipment. These users still need accommodation.

8. Keep up with Accessibility Developments

Screen readers and browsers are continuously evolving. Old problems may be solved and new ones created. Evolving technologies will create new accessibility issues.

BUT, if you incorporate accessibility now, you will be better prepared for new developments in the future and less likely to need to make major changes.

End of Seminar