Some Accessibility Gotchas
Tutorial Page 6
In the years of discussion about accessibility in Web design, some implementation myths have emerged.
Below are some of the most common misconceptions.
1. There’s only a small audience for accessibility.
Myth—Accessibility compliance only benefits users registered with the Office of Disability Services.
Reality—Accessibility accommodations benefit users beyond those with an “official disability.” Consider how many people watch closed captions on TV, even if they are not deaf. At some point almost all of us will be in a situation where an image link is broken, colors are not distinguishable, text is too small, audio is not working, we cannot see the whole screen or we cannot move the mouse properly.
2. Only accessibility experts can implement accessibility fixes.
Myth—Accessibility issues are so arcane only an expert can really fix them.
Reality—Most accessibility fixes are simple to understand and implement once the content creator is aware of the tools and techniques. For instance, techniques in creating accessible Word documents involve applying tools such as Heading styles, the table of contents generator and appropriate selection of fonts. The most specialized tool, ALT tagging images, can be quickly accessed by right-clicking the image and selecting the Format Picture option. The same is true for PowerPoint, Canvas, and many other common tools.
3. 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 accessibility measures from the beginning.
Myth 2—I rarely get accommodation requests for a course and then usually to extend deadlines. Accessibility isn’t an issue for this course.
Reality—The number of cases of accommodations for blind, low vision and deaf students has increased significantly at Penn State, particularly for online courses. Students may also wait until the semester is partly complete before requesting assistance. Developing an accessibility plan may save instructors remediation effort in the future.
4. Fixing just the Blockers fixes all major issues
Myth—Once I make sure the blockers are fixed, the remaining issues are relatively minor.
Reality—Although Penn State designated some blockers as being important to fix first, the other remaining issues such as keyboard accessibility, color coding and others can pose serious issues, even to screen reader issues. A full accessibility plan should address all issues.
5. If it’s audio, then a screen reader can access it.
Myth—If my content is delivered by audio, then by default a visually impaired user can access it.
Reality—The navigation to the audio (including the login process) may not be accessible.
6. ARIA/Standards/CSS styling will guarantee accessibility.
Myth—If I use CSS, create standards compliant code and implement ARIA, I can guarantee that my site will be accessible.
Reality—Although these techniques can significantly improve accessibility if implemented properly, you can also create additional accessibility issues if you use the markup incorrectly.
The same statement applies to other standards such as HTML 5, XML, MathML, Unicode, etc. These standards facilitate data exchange, and are easier for assistive technologies to work with, but do not guarantee accessibility.
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 standards-compliant.
Reality—None of these eliminations are required by WCAG 2.0. What is required is that these tools be implemented with sufficient information for a screen reader to use. In most cases, this only requires the addition of a few specific attributes. Even JavaScript programmers have developed techniques to create accessible code, especially in terms of the recently developed ARIA standard
8. Accessible design interferes with design.
Myth—An accessible Web site is a plain
Web site or one without any design innovations.
Reality—More complex designs can be implemented while remaining accessible. The key is to incorporate elements that do not interfere with legibility, screen reader access or keyboard access. See the following accessibility Web sites for examples: WebAIM, Jim Thatcher Accessibility Tutorials, and Accessify.com.
It is also the case that many accessibility principles (e.g. good color contrast, good semantic structure) do follow good design and Web development principles.
9. A text-only or an “Accessible site” is a good accessibility option.
Myth—Creating a parallel, text-only site or service while maintaining an inaccessible site 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 content and plug-ins. The reasons include:
- 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.
- 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.
- Newer screen readers can actually process accessible HTML better than they can a text-only site.
- Text-only sites may address some accessibility issues specific to screenreaders, but not all accessibility issues.
- Accessibility goes beyond “text-only,” so the original site must be reviewed in any case.
NOTE: It can be beneficial to provide portions content in alternate formats to enhance accessibility. Examples include Flash vs. non-Flash, PDF vs. Word and other alternate formats.
10. Accessibility requires EM and STRONG tags.
Myth—You must replace the B (bold
face) and I (italics) tags with STRONG and EM tags
to be compliant.
Reality—Although this is recommended in the Web Standards community for a variety of reasons, it makes little practical impact in visual browsers or screen readers.
11. Minimum WCAG 2.0 compliance fixes all problems.
Myth—If you meet the minimum requirements for WCAG 2.0 compliance, you will never have to worry about accessibility issues again.
Reality—Not all user needs can be accounted for in any guideline. A user may require further assistance because of a particular combination of needs. In addition, advances in Internet options will inevitably create additional accessibility issues. This page and this site are continually updated to ensure compliance with accessibility guidelines. The goal of WCAG 2.0 is to address common barriers to usability in order to reduce future accessibility issues.