In this chapter
·
Introduction
to what is meant by accessibility and access to information on the Internet for
people with disabilities
·
US Federal
Regulations for accessibility
·
How to begin
the task of creating accessible Internet based content
·
Being an
advocate for accessible content
Since the Internet was founded, it has become an easy
way to publish and locate information.
According to the American Heritage Dictionary, something is
accessible when it can be “easily obtained.”
When information on the Web is accessible, everyone can find and use it.
Accessibility today has two meanings for Web content:
Information is accessible when it meets U.S. federal
regulations for Web content. As of June 25, 2001, federally maintained Web
sites and networks are required to comply with these accessibility standards.
Information is also accessible when it achieves the highest
level of usability. In addition to federal regulations, there are many more
suggestions that help everyone to find and use Web-based information. For
additional information, contact the W3C® or visit
http://www.w3.org/WAI.
In this book, the accessibility problem is introduced and
comprehensive information is provided to assist your organization in producing
and maintaining accessible content.
According to the US Census Bureau, December 1997 U.S. Census
brief, one in five Americans have some kind of legal disability. (Source: December 1997 US Census Brief, “Disabilities
Affect One-Fifth of all Americans,” available at http://www.census.gov/prod/3/97/pubs/cenbr975.pdf.)
The people impacted by these disabilities may require assistive
technologies to access Web-based information. Most people use a browser like
Microsoft® Internet Explorer™ or Netscape® Navigator™ to view Web-based
information. But since popular browsers do not accommodate the needs of all
people, some people use assistive technologies in conjunction with their
Web browser. Assistive technologies, working in conjunction with the browsers,
allow disabled users to access the Web-based information.
For example, if you are blind, you might use an automated
screen reader. The screen reader, a software program, not only reads aloud the body
text on a page, but also
describes Web elements such as images. However, in order for a screen reader to
describe images and other Web elements to the user, the HTML or other markup
language used to code the page must make this information available to the
screen reader.
When a screen reader encounters an image in a Web document
it cannot describe the image to the user, unless the author of the Web document
has provided alternative text. The alternative text, sometimes created in HTML
by using the “alt attribute”, provides a description of the image to the screen
reader. If an image in a Web document is a red and white circle and the
alternative text description is “bull’s eye”, the screen reader can tell the
user that there is a bull’s eye in the Web document. When no alternative text
is present for non-text information, the screen reader cannot provide helpful
information to the user.
Some Web authors use animations and sounds to convey
information. These Web elements and techniques pose similar access problems for
disabled users. Someone with a visual impairment or hearing difficulty cannot get
helpful information from an audio-based presentation without a text
description. A text description for an animation can help a user with a visual
impairment, in the same way that a text description for sound can help a user
with hearing difficulty. Text descriptions for sound are similar to captioning
for television.
In addition to accessibility standards for images and
multimedia elements, there are standards that allow users to view and easily
use pages even when their browsers and assistive technologies do not support
display features.
Prior to accessibility laws, many Web sites were not
compatible with assistive technologies. This shortfall left a large population
of users unable to access information on the Web. Accessibility laws ensure
that everyone can find and use the same information.
If you were to ask someone in your organization what an
accessible Web site is they would probably reply that an accessible Web site is
one that is usable by a blind person. In fact, an accessible Web site does aid
in making the information on the site accessible to a blind person while also
enabling people with a variety of other disabilities to do so.
Some common disabilities:
- Blind Users
- Color Blind Users
- Users with weak vision that cannot read small text
- Deaf users
- Hard of hearing users
- Users that cannot use a mouse
- Users with disabilities like arthritis or other motor-
control issues
- Photosensitive epilepsy – Not as common but it is
addressed by the standard.
If you look at the list of possible disabilities addressed
by the accessibility standards you can gain a greater awareness as to the scope
of the standards and their importance. The following is a list of disabilities,
the common issues they present and/or solutions that can address access issues:
Blind
Software that reads content out
loud or solutions that translate the content to brail
Color Blind
Site must be developed to not rely
on color
Low Vision
Users with low or weak vision will
use browser software or magnifying software to adjust for disability
Deaf or hard of hearing
Rely on captioning or text
transcripts of audio content
Motor-Challenged, unable to use keyboard and/or mouse
People who do not use a mouse rely
on keyboard shortcuts or pointing devices held in the mouth
Additionally speech interfaces
provide a potential solution
Photosensitive epilepsy
People with this disability could
have a seizure triggered if the computer screen has movement, flickering or
animation, which is not in compliance with the rule.
Since the beginning of the “Information Age”, technology has
been developing rapidly. Television shows from decades past, like Star Trek®, portrayed people walking around
with hand-held communicators, and speaking to their computers to use them.
Today this is a reality – cellular phones and beepers allow us to remain in
constant communication, and handheld computing is commonplace. People are using
small devices to download e-mail, get stock quotes, find driving directions,
and communicate with friends and relatives. Scenarios like this are becoming
more common, and technology providers no longer presume that most people use a
desktop computer with a keyboard and a pointing device to surf the Web.
Accessibility laws are making Web-based information user-friendly for all
users.
Compliance with these standards, not only assists users of
assistive technologies, but also can improve access to the Web for these
hand-held, wireless devices. These laws are based on best practices for Web
authoring and information technology. While many of the laws directly benefit
users with disabilities, who might rely on assistive technologies to view
information, the laws also benefit everyone else.
The future of Web accessibility is optimistic. Since federal
accessibility laws have been adopted, technology corporations have publicly
declared their commitment to these standards, even though they are not required
to do so by law. Moreover, technology executives are collaborating on their
visionary ideas for accessibility that extend far beyond legal requirements.
Industry leaders have realized that the true power of the Internet lies in its
ability to deliver information to all people.
No one knows for certain how accessibility will be made
possible in the future. Perhaps it will take the form of a dynamic browser, so
that users will no longer need assistive technologies. Or maybe Web authoring
software of the future will compensate for the current shortfalls of Web-based
information. But until mainstream technology allows all users to access the
same information, Web authors must make provisions in the source code of their
Web documents so that Web information can be processed by assistive
technologies. This book can help you do this.
Federal regulations governing accessible Web content resulted
from The Rehabilitation Act Amendments of 1998, which included The Workforce Investment Act of 1998 and stemmed from The Rehabilitation Act of 1973.
Section 508 contains regulations for information technology.
These regulations have been issued in publication S-40, Electronic
Information Technology Accessibility Standards; Final Rule. This document
states that “when Federal agencies develop, procure, maintain, or use
electronic and information technology, they shall ensure that the electronic
and information technology allows Federal employees with disabilities to have
access to, and use of information and data, by Federal employees who are not
individuals with disabilities, unless an undue burden
would be imposed on the agency.”
Section 508 addresses accessibility for electronic and
information technology. Under Section 508, there are several subparts:
- Subpart A contains general information about the purpose,
application, and implementation of 508 standards.
- Subpart B contains technical standards, including
Web-based intranet and Internet information and applications. Other
components of Subpart B include standards for software products, operating
systems, telecommunications products, video and multimedia products,
self-contained products, and desktop and portable computers.
- Subpart C contains functional performance criteria.
- Subpart D contains standards for information, documentation,
and support.
Subpart B contains §1194.22, the section that addresses
standards for Web-based intranet and Internet information and applications.
Subpart B - Technical Standards in its entirety
contains the following subsections:
§1194.21
Software Applications and Operating Systems
§1194.22
Web-based Intranet and Internet Information and Applications
§1194.23
Telecommunications Products
§1194.24
Video and Multimedia Products
§1194.25 Self
Contained, Closed Products
§1194.26
Desktop and Portable Computers
To get a copy of publication S-40 Electronic Information
Technology Accessibility Standards; Final Rule, contact the Access Board’s automated publications order line. Dial (202) 272-5435, press 2 on the telephone
keypad, and then press 1. Request publication S-40, Electronic Information
Technology Accessibility Standards; Final Rule.
If you use a TTY, call (202) 272-5449. Record the name,
address, and telephone number of the person requesting publication S-40, Electronic
Information Technology Accessibility Standards; Final Rule.
Copies are available in alternative formats including
cassette tape, Braille, large print, or computer disk.
The publication is also available on the Internet at:
http://www.access-board.gov/sec508/508standards.htm
The US Access Board is conducting a review and update of its
access standards for electronic and information technology covered by Section
508 of the Rehabilitation Act. The Telecommunications and Electronic and
Information Technology Advisory Committee has been working on this revision for
the greater part of 2007 and 2007. More information about the technical refresh
of Section 508 can be found at: http://www.access-board.gov/sec508/update-index.htm.
Additional information may be found at: http://teitac.org/
The W3Câ’s Web
accessibility initiative group (WAI) pursues
accessibility of the Web through five primary areas of work:
- Technology
- Guidelines
- Tools
- Education and outreach
- Research and development.
For more information on the W3C
visit their Web site at:
http://www.w3.org/WAI/
From here you can find
accessibility news and all associated Web accessibility information, standards,
and efforts available from the W3C’s Accessibility group.
The W3C is in the process of
updating its recommendations and guidance for Web Accessibility through the
creation of the Web Content Accessibility Guidelines version 2.0. More
information about this update can be found at: http://www.w3.org/WAI/intro/wcag20.php
Section 508 requires that federally maintained Web sites and
intranets be in compliance with the standards after June 25, 2001. If you are
uncertain as to whether or not your organization is required by law to comply
with accessibility standards, contact the Access Board or visit
http://www.access-board.gov.
Obtain a copy of publication S-40, Electronic
Information Technology Accessibility Standards; Final Rule, and become
familiar with it. This guide also helps to explain laws pertaining to Web
content on the Internet and intranets.
Another document from the Access
Board provides specific techniques on how you can comply with accessibility
standards. Visit http://www.access-board.gov/ sec508/guide/1194.22.htm for more
information.
There are many resources available
to help you develop accessible Web content. The Access Board, the organization
administering federal accessibility laws, offers technical support and
additional information on accessibility.
Also consider W3C®,
Trace Research & Development Center, National Center for Accessible Media,
and National Arts and Disability Center. Contact these agencies directly, or
visit their Web sites for more information.
It is important to stay informed
for several reasons:
·
As technology develops, accessibility standards are certain to
change.
·
New techniques for creating accessible Web content are being
published frequently.
·
As developers enhance the capabilities of browsers and markup
language for Web documents, achieving accessibility will become easier.
There are many software solutions
on the market to help you verify and achieve compliance with accessibility
laws.
The Access Board provides technical assistance with the
implementation of Section 508 standards.
The Access Board provides online documentation to help you
get started. Visit http://www.access-board.gov/sec508/guide/1194.22.htm for
more information. Or contact the Access Board for support.
The Access Board
Office of Technical and Information Services
1331 F Street, NW, Suite 1000
Washington, DC 20004-1111
Voice: (800) 872-2253 or (800)
993-2822 (TTY), weekdays 10-5:30 EST (Wed. 10AM–2PM)
Fax: (202) 272-5447
Web: http://www.access-board.gov
E-mail: 508@access-board.gov
Accessibility laws have been issued in publication S-40, Electronic
Information Technology Accessibility Standards; Final Rule.
The standards that appear in this book have been interpreted
from their original form. To read the standards in original form, request a
copy of publication S-40, Electronic Information Technology Accessibility
Standards; Final Rule.
Section 508, Subpart B, §1194.22 explains the accessibility
standards for Web-based intranet and Internet information and applications.
The Section 508 Standards, which were introduced as a rule
for federal Web site development, are an extension and/or modification of the
W3C standards. In the appendix of this book there is a mapping of W3C
standards to 508 Standards. The overall differences between these two standards
are minimal.
In the near term, it is safe to say that if your intentions
are to develop a site with the goal of its being accessible then you can follow
W3C Priority One standards or Section 508 Standards. Supporting both standards
is also simple once you have made the decision to create an accessible Web
site.
Developers often ask, “Why should our site be accessible?”
Aside from any legal or statutory requirements, the answer to this question is
simple - offering equal access to disabled users is compelling, and for many
reasons:
- Build your Web site audience.
- Take a position of leadership in your particular business
sector.
- Grow a loyal customer base.
- If you are doing business with the government, it is the
law.
- It is apparent for non-government Web sites that it will
become the law.
- The cost of retrofitting is much higher than building an
accessible site from scratch.
- It simply makes good business sense to increase the number
of your potential customers.
- It is the right thing to do at a minimal cost.
It is hard to imagine why one would not want to build an
accessible Web site. The information and ideas expressed in this book will
illustrate that it is not difficult to achieve and maintain an accessible Web
site. The remainder of this chapter deals with how to make your content accessible.
Full examples are provided as part of the descriptions.
There are many good reasons for supporting the creation of
accessible Web content. It is important to recognize that these changes will
not happen overnight. Simply put, an advocate is someone that pleads on another’s
behalf. The most successful advocates in history have been those who have
sought to bring people to their position while constructively demonstrating the
deficits of current circumstances.
Advocates within organizations should start out by trying to
educate as many people as possible about the accessibility issue. We have
discussed many compelling reasons why an organization should develop Web sites
to be accessible. It should be very easy to communicate them to people in your
organization. Once it is clear that “developing accessible” is achievable,
affordable, and can provide a competitive edge, it will become common rather
than the exception.
The following types of activities are recommended for
accessibility advocates:
- Educate your team members
- Educate individuals outside of your team
- Whenever you create documentation or any type of
information that will be viewed by others, make it accessible, even if it
is not a requirement or policy
- Participate in local or national organizations related to
the accessibility issue
The following types of activities should be AVOIDED:
- Do not tell people that they will lose site visitors if
their site is not accessible, instead explain about the increased user
base they would have if their site was accessible.
- Do not attack a manager’s character if they turn you down
for resources to perform an accessibility project; instead educate them by
justifying the project in a way that disproves their reasoning for
initially rejecting your project.
Remember, if people fully understand the accessibility issue
and the positive impact they can make on the issue by building accessible, then
they are likely to do so.
It is very important to educate your Web team on Web content
accessibility. One frequent “misconception” about accessibility compliance,
relates to the use of a second set of content that is developed as a text-only
version of a site. Some developers have been told that a second set of content,
provided as a text-only site, will be an acceptable replacement to making a
site accessible.
This simply may not be true and defeats the spirit and the
years of work and research behind making electronic information accessible to
all in equal form and content. The full text page cannot portray the true
meaning of content unless the content is, by default, full text for the
following reasons:
- If an image had no meaning it would not have been used in
the first place.
- If a navigation element had no meaning it would not have
been used in the first place.
Ask yourself a simple question:
If I create a full text page that actually contains the same
content as the main page, does it satisfy accessibility requirements for all of
the people with potential disabilities that may be viewing the site?
- Blind
- Color Blind
- Weak vision
- Deaf or hard of hearing
- Inability to use mouse
- Motor-Control Challenges
Answer: Even if you were able to address all of these
issues in your text-only version of the Web site, from a management
perspective, you will now be faced with synchronizing, updating, and
maintaining two versions of the same site. When dealing with the accessibility
problem it is more cost effective to make one set of content that is accessible
by all!
From another perspective full text can be a management
nightmare. The goal is to deliver content with exact meaning to all users all
of the time. Full text pages are created in several ways:
Automated
This is probably the best method however there is a high
probability that some data will not translate which means that the content will
not be the same. The automated translation of a Web site into a text-only Web
site, will meet the same limitations that assistive technologies face - it can
only work with information that already has the text equivalents behind
non-text elements.
Manual
This method can be time consuming not only during creation,
but also from an upkeep perspective. In order to make a simple change in a page
means you must now remember to update the text page. There is a high
probability that the pages will be out of sync after several updates.
Content Management Systems
Content Management systems will encounter the same
challenges described with the automated translation example above. Because a
simple translation is not likely, the best way to handle this is to create
accessible templates and code from the beginning versus attempting to come up
with full text alternative content with equivalent meaning.
Now if full text is the only way you can go then you are
permitted to do this - just remember the challenges:
- High cost to implement effective system.
- Content Synchronization.
- Difficult to translate meaning of graphics via automation.
In this chapter
·
Introduction
to Section 508 and W3C WCAG Priority one guidelines
·
Detail on
disabilities addressed by each checkpoint
·
Summary of
how to validate each checkpoint
The Section 508 and WCAG Priority One standards are very
similar to each other with a few subtle differences. For this chapter we will
cover section 508 checkpoints and their meanings.
See
Appendix A for a complete summary of Section 1194.22 vs. W3C WCAG Priority One.
This map will allow developers to use the following information regardless of
the standards with which they are developing their site to comply.
This chapter provides a conceptual overview of accessibility
requirements, detailing both why they are important and providing a general
overview of how to correct accessibility issues. For a complete reference on
HTML Markup for Accessible design please see Chapter 7 for the Tutorial and
HTML Examples.
(a)
A text equivalent for every non-text element shall be provided
A text equivalent conveys the same information to the user
as the original non-text element. The section 508 guideline points out the
following items as examples of elements that require text equivalents.
- Buttons
- Check Boxes
- Pictures/Images
- Embedded or
Streaming audio or video.
Special W3C vs. 508
The mapped
W3C guideline, 1.1, includes other items, not specified in Section 508 (a),
however included under the federal guidelines.
- Input
Elements
- Object
Elements
- Applet
Elements
- Frameset
Elements
- IFrames
- Anchors
- Area
Elements
These are
covered later in 508 in other sections like (n) as well as being required but
not implicitly mentioned in paragraph (a).
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Blind
- Weak vision
- Deaf or hard of hearing
Dealing with Non-text elements
Chapter 6 of this book goes into detail on how to write text
equivalents. The most important points to remember are:
- The Alternative text should fully represent the image
meaning and its purpose to the person viewing the web page.
- If a long description is required for the image the
longdesc attribute can be utilized to post another URL, which will contain
additional information.
Testing your page for compliance to paragraph (a)
It is easy to test your page for compliance to paragraph
(a). Automated testing tool such as HiSoftware’s AccVerify can quickly test a
page or an entire Web site.
(b) Equivalent
alternatives for any multimedia presentation shall be synchronized with the
presentation.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Blind
- Weak vision
- Deaf or hard of hearing
Dealing with Alternatives for multimedia content
A video presentation with an audio component requires
captioning. The captioning must be completely synchronized with the audio
presentation to allow for the viewer to follow the meaning of the content.
If there is only an audio component there is no need for
captioning, however, a text equivalent (Full Transcript) “must” be made
available.
If there is a slide show like a PowerPoint slide show
available but it is “visual only”, the graphics need to have alternative text
representations.
EXAMPLE and Tip FOR POWERPOINT presentations
For those providing silent Microsoft PowerPoint
presentations via the Internet remember to provide alternative text for your
images. In PowerPoint 2000 and above you can do this by following the steps
below:
- Select on the Image that that needs alternative text
- Select Format | Format Picture from the Main Menu
- Select the “Web” Tab
- Type in the Alternative Text
- Click on OK
Testing your page for compliance to paragraph (b)
This is a visual checkpoint. When content developers are
delivering multimedia content they must make sure it is in compliance with
paragraph (b)
(c)
Web pages shall be designed so that all information conveyed with color is also
available without color.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Blind
- Weak vision
- Color Blind
Dealing with Color
The use of color does not prevent a page from meeting the
accessibility requirements. A junior designer may believe this is the case; it
is important that designers understand that they can use color and be in
compliance with accessibility standards. This paragraph (checkpoint) deals with
the use of color alone in indicating action or meaning.
Notes on color
Do not display emphasis of a word by color alone.
For example do not create a form that requires users to fill out all form field
values that are “marked in red.” Use HTML Markup like <Strong> or
<EM>. Do not use color alone in an image to indicate an action.
Example: Do not say, “Press the red button to
cancel your order or the green button to complete your order”. Color can
definitely be used to augment the design of form but use alternative text and
/or text on the image to signify cancel and finish.
Testing your page for compliance to paragraph (c)
It is easy to test your page for compliance to paragraph
(c). This check is clearly a visual check and can be completed by testing the
output devices that provide a black and white output.
Printer
Print your Web page on a black and
white printer. View the output to assure that all text and images are still
visible, and that the emphasis required is still visible.
Screen
View your page on a black and white
monitor or set you monitor to the aforementioned view and view the screen to
assure that color was not the only way that information has been presented.
(d)
Documents shall be organized so they are readable without requiring an
associated style sheet.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Blind
- Color Blind
- Weak vision
Dealing with Style sheets
Style Sheets are intended to separate presentation from
content. They provide an easy and efficient way to format HTML documents. Style
Sheets enhance the effectiveness of HTML as well as simplify the process of
maintaining a Web site. Additionally, the use of Style Sheets enables users to
set viewing preferences to accommodate their disability.
With this in mind it is important that a Web site developer
does not design a page that will interfere with user defined style sheets.
Testing your page for compliance to paragraph (d)
It is easy to test your page for compliance to paragraph
(d). Simply turn off support for style sheets, all information and its meaning
should be present without style sheets. Additionally, you can test with a user
defined style sheet to make sure that it does not interfere with the ability to
understand and navigate the site.
(e)
Redundant text links shall be provided for each active region of a server-side
image map.
(f)
Client-side image maps shall be provided instead of server-side image maps
except where the regions cannot be defined with an available geometric
shape.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Blind
- Color Blind
- Weak vision
- Inability to use mouse
- Motor-Control Challenges
Dealing with Image Maps
An image map is a single image that is used to offer
multiple links to content in a Web site. Image maps are rarely actual maps!
When a user selects a link on an image map it takes them to the link connected
with the referenced part of the image.
There are two types of Image Maps, client and server side.
The main difference between the two is where the actual processing of a
visitors action taken on the map is translated.
The rule for paragraph (e) is necessary because the actual
link is processed on the server so it is not available to users of assistive
technology because of their inability to see the map. By presenting the user
with a list of links, the map is made accessible.
The rule for paragraph (f) is necessary because it allows
the user of assistive technology to easily activate regions of the image map.
Related Rule: Paragraph (a)
Testing your page for compliance to paragraph (e) & (f)
It is easy to test your page for compliance to paragraphs
(e) & (f). AccVerify can quickly test an entire site or page.
(g) Row and column headers shall be identified for data
tables.
(h)
Markup shall be used to associate data cells and header cells for data tables
that have two or more logical levels of row or column headers.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
Dealing with TABLES
Tables can be used for design/Layout or as a means to present
data. Tables that are used to present data should be structured so that those
users who cannot view the data with its visual reference points can easily
navigate them. The structure of these tables implies meaning to the information
within them, based on the organization of the table. Therefore, a screen reader
should be able to utilize this table structure.
Making a Table Accessible
The following steps are designed to enable users of
assistive technology to understand and navigate tables successfully.
1. Determine
the Table Type (If Layout versus data table, than no further action is
required. *Note the developer should make sure that the table used for layout
makes sense when linearized.)
2. For
Data Tables first enter a table summary:
The summary attribute allows the developer to provide a
summary of the tables information.
Screen readers can take advantage of this non-visual
(does not appear on the page when viewed in a browser) attribute.
The summary should provide the page viewer with:
·
Overview of the table
·
Overview of table contents
·
Overview of the Structure
·
Overview of the Tables purpose
Optionally
the developer can use the Caption tag.
The
caption appears as part of the document text on a page with a table. The
Caption tag is visible on the Web Page.
- There are cells in the tables that serve as headers, or
labels for the information in the respective row or column. Headers must
be identified as header cells. In this step of making the table
accessible, you need to locate header cells in the table, and then change
the TD tag to a TH tag.
4. Identify
Row and Column Headers
Simple tables - consider identifying row and
column headers with the scope attribute.
Complex tables - consider identifying row
and column headers with the headers attribute. If the table has more than one
row or more than one column of header cells, consider using the axis attribute
to group them together.
- Group multiple header rows or header columns. When
header cells are clearly identified the significance of the data cells is
easily identified.
Testing your page for compliance to paragraph (G) & (H)
It is easy to test your page for compliance to paragraphs
(g) & (h). AccVerify can quickly test your Web page or your entire Web
site. Remember a tool, which can filter out layout tables, will offer a
streamlined approach to testing tables for accessibility.
(i) Frames shall be titled with text that facilitates frame
identification and navigation.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
Dealing with Frames
A Framed Site
uses combinations of HTML documents, displayed together in the browser to
visually divide the computer screen into separate and distinct areas that can
be separately redrawn depending on user action. Frames present difficulties for
users with disabilities when those frames are not identifiable to assistive
technology. Users of assistive technology will find it difficult to navigate
frames if the differences between the frames in the frameset are not clearly
defined.
To facilitate
easy navigation with frames use the “title“ attribute available to the frame
element.
Testing your page for compliance to paragraph (i)
It is easy to test your page for compliance to paragraph
(I). AccVerify can quickly test an entire site or page.
(j) Pages shall be designed to avoid causing the screen to
flicker with a frequency greater than 2 Hz and lower than 55 Hz.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
Dealing with PARAGRAPH (j)
The developer should prevent the screen from:
- Flashing
- Flickering
- Blinking
- Or Having Staggered Movement from a control like the
marquee or a News Bot
If the screen behaves in one of the manners listed above, it
could trigger a seizure in an individual with the aforementioned disability.
Testing your page for compliance to paragraph (j)
Flashing or flickering elements should be avoided and should
be identified by your testing tool. This is a visual as well as an automated
test.
(k) A text-only page, with equivalent information or
functionality, shall be provided to make a Web site comply with the provisions
of these standards, when compliance cannot be accomplished in any other way.
The content of the text-only page shall be updated whenever the primary page
changes.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Potentially all disabilities referred to in the standards
Dealing with TEXT-only Pages
Paragraph (k) provides a failsafe measure for pages or
content that cannot be made accessible. It requires that there be an accessible
alternative. This is commonly referred to as a “Full Text” version of a Web
site or page. This alternative should truly be avoided. The cost of maintaining
this solution and the likelihood of incomplete content is too high.
Additionally the task to make a Web site or Web site content accessible is
generally not out of the reach of any organization.
See
Chapter one for more information on full text versions of content.
Testing your page for compliance to paragraph (k)
This practice is costly to maintain and to test. The
requirement is clear that the content on a non-full text page be identical to a
full text page. Every page of content must be reviewed in order to assure that
it is in compliance. Because of the detailed testing this method requires, it
is strongly recommended that this alternative be used only when there is
absolutely no way to make the page accessible.
(l) When pages utilize scripting languages to display
content, or to create interface elements, the information provided by the
script shall be identified with functional text that can be read by assistive
technology.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Potentially all disabilities referred to in the standards
Dealing with SCRIPTS
All JavaScript URLS should have meaningful text so as to be
useful for people with disabilities to follow. Developers should avoid event handlers
as the only method for navigating or completing a page.
Problematic Handlers:
- OnClick
- OnDblClick
- OnMouseDown
- OnMouseUp
- OnMouseOver
- OnMouseOut
- onChange
Event Handlers that require no user interaction and are
device independent are not problematic:
- OnLoad
- OnUnload
- OnBlur
- OnFocus
Remember that all script function should include a NOSCRIPT
tag for those browsers or assistive technologies that do not have script
support.
Testing your page for compliance to paragraph (l)
It is easy to test your page for compliance to paragraph
(l). AccVerify can quickly test an entire site or page for compliance. The
identification of every JavaScript event handler is a good place to start on a
comprehensive site to begin the assessment process.
(m) When a Web page requires that an applet, plug-in or
other application be present on the client system to interpret page content,
the page must provide a link to a plug-in or applet that complies with
§1194.21(a) through (l).
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Potentially all disabilities referred to in the standards
Dealing with applet or plug-ins
This is one of the more complex checkpoints or paragraphs
with which a Web content developer or site manager needs to deal. The reason it
is so complex is because it becomes both a Web content and potentially software
accessibility verification issue.
The simple part of this paragraph is if a plug-in, object,
applet or viewer is required then the developer must provide a link on the page
so the user can get easy access to the required component.
NOTE: If you have a link to 30
pdfs on your page there is no need to put 30 links to the PDF viewer! This is a
common an unnecessary practice.
The problem with complying with this paragraph is that
developers must assure that the plug-in required is accessible. Chapter Eight
of this book provides more information on software accessibility.
Testing your page for compliance to paragraph (m)
One must test either Web or software standards for any
applet, object or plug-in used separately. Check with the provider of the
plug-in or applet/object for the status of the products accessibility.
(n) When electronic forms are designed to be completed
on-line, the form shall allow people using assistive technology to access the
information, field elements, and functionality required for completion and
submission of the form, including all directions and cues.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Potentially all disabilities referred to in the standards
Dealing with ELECTRONIC FORMS
The most important thing to remember when providing
electronic forms is that you “SHOULD” develop the forms to be accessible for
both simple and sophisticated screen readers and assistive technologies. This
means that the following can be used to make the form accessible:
- Predefined values in text area
- Title text on inputs
- Labels for easy navigation
Stay away from solutions that do not work with all screen
readers.
Testing your page for compliance to paragraph (N)
It is easy to test your page for compliance to paragraph
(n). AccVerify can quickly test an entire site or page for compliance.
(o) A method shall be provided that permits users to skip
repetitive navigation links.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Potentially all disabilities referred to in the standards
Dealing with NAVIGATION LINKS
Most sites are developed with structure. By having structure
you most likely have sections of your Web site designed specifically for
navigation of the entire site. One of the easiest ways to deal with this
paragraph is to put a bookmark on the page for where the content starts and a
link on the page navigation section. This allows the user to select the link to
skip directly to the content bookmark that you placed on the page.
Testing your page for compliance to paragraph (o)
This test is a visual checkpoint. When validating that the
skip navigation links works you should visually verify that:
- The bookmark that you send the user to does not skip ANY
Non-Text content that is not related to navigation
- The bookmark that you send the user to does not skip ANY
Text content that is not related to navigation
(p) When a timed response is required, the user shall be
alerted and given sufficient time to indicate more time is required.
Disabilities Addressed by this paragraph
The following disabilities are addressed by this paragraph:
- Potentially all disabilities referred to in the standards
Dealing with TIMED Responses
A Timed response is best described as a page that requires
some sort of user input, based on script or coding, that only gives a user a
specified amount of time to perform some action before:
- The page expires
- Clearing Form Input
- Redirecting the user to another page
The completion of the action required in the time allotted
may be difficult for a user with a disability covered by this paragraph and
general Section 508 rule.
Any content that requires a timed response must alert the
user that they are running out of time and allow them via a prompt to request
more time.
Testing your page for compliance to paragraph (p)
This test should be performed on all pages with a timed response;
it could be both a visual and / or automated test.
In this chapter
·
Introduction
to the W3C WCAG Priority Two guidelines
·
Detail on
disabilities addressed by each checkpoint
·
Summary of
how to validate each checkpoint
The Section 508 and WCAG Priority One standards are very
similar to each other with a few subtle differences. For this chapter we will
cover Section 508 checkpoints and their meanings. This chapter provides a
conceptual overview of accessibility requirements, detailing both why they are
important and providing a general overview of how to correct accessibility
issues. For a complete reference on HTML Markup for Accessible design please
see Chapter 8 for the Tutorial and HTML Examples.
2.2 Ensure that foreground and background color
combinations provide sufficient contrast when viewed by someone having color
deficits or when viewed on a black and white screen. (Note for Priority two
this addresses images only. Text is covered by priority three.)
A site using images should comply with 2.2 as required by
Priority Two to assure that the content is usable and accessible.
Disabilities Addressed by this CHECKPOINT
The following disabilities are addressed by this paragraph:
- Weak vision
- Color Deficits
- Aging Eyes
- Hardware limits such as a black and white monitor
DEALING WITH COLOR CONTRAST
The biggest problem with color contrast that is experienced
by developers is the false presumption that if the contrast looks good for them
it will be fine for everyone else. So the first question must be what is contrast?
Contrast is simply the difference in luminance reflected between two adjacent
colors. Given this definition Black Text on a Black Background would be zero
contrast. The W3C is clear that one should always set both the foreground and
background colors, which are recommended by this text as well.
Testing your page for compliance to WCAG P2 2.2
It is easy to test your page for compliance to checkpoint
2.2. Testing tools such as HiSoftware’s AccVerify can quickly test a page for
compliance to visual checkpoints. For 2.2 simply follow these steps with
AccVerify:
·
Select Tools
·
Select Interaction Builder
·
Enter the page you want to test in the address box
·
Press Enter or select the GO Button
·
Select the test preview mode
·
Select the color button
·
Evaluate for compliance
3.1 When an appropriate markup language exists, use
markup rather than images to convey information.
Disabilities Addressed by this CHECKPOINT
The following disabilities are addressed by this paragraph:
- Weak vision
- Aging Eyes
- Screen Reader Users
DEALING WITH MARKUP VERSUS IMAGES
In the early days of the Internet many people who desired to
control the overall quality of presentation did tend to make text in the form
of an image so that they could control the presentation regardless of the
browser. Also, in cases of math equations a web developer unfamiliar with other
solutions would do the same, representing everything with an image.
Testing your page for compliance to WCAG P2 3.1
It is easy to test your page for compliance to checkpoint 3.1.
Testing tool such as HiSoftware’s AccVerify can quickly test a page for
compliance to visual checkpoints. For validations of checkpoint 3.1 simply
follow these steps:
1. Select
Tools
2. Select
Interaction Builder
3. Enter
the page you want to test in the address box
4. Press
Enter or select the GO Button
5. Select
the test preview mode
6. Select
the color button
3.2 Create documents that validate to published formal
grammars.
Disabilities Addressed by this CHECKPOINT
Publishing to formal grammars is a way to attempt to develop
based on standards that creators of assistive technology can rely on in
developing their solutions. Theoretically this could impact any disability so
pointing out specifics would not be helpful or provide guidance.
Testing your page for compliance to WCAG P2 3.2
The most uniform way to test for compliance to this
checkpoint is to use the W3C HTML Markup Validation Service. This service
allows you to test both local and live pages. For validation of 3.2 simply
follow these steps:
1. Browse
to http://validator.w3.org/
2. Enter
your URL
3. Select
the [Check] button
4. Review
your results
3.3 Use style sheets to control layout and presentation.
Disabilities Addressed by this CHECKPOINT
Separating Structure and Presentation is another way of
assuring that assistive technologies will have an easier job of getting content
to the users of the specific assistive technology.
DEALING WITH Atructure versus Presentation
One of the most frequent topics of discussion between
designers of websites is the question of structure versus presentation. This
again comes from the days of print versus electronic presentation. The best way
to work with presentation is with style sheets versus inline presentation
elements. This is also very important when considering the structure of a
document. From a structure perspective you should use heading elements, say
(H1-H6). This does not prevent you from using Horizontal Rules, Bold, Large
Fonts, etc. They should be used in the style sheet versus as part of the
document structure.
Testing your page for compliance to WCAG P2 3.3
It is easy to test your page for compliance to checkpoint 3.3.
A Testing tool, such as HiSoftware’s AccVerify, can quickly test a page for
compliance to visual checkpoints. For validations of checkpoint 3.3 simply
follow these steps:
1. Set
tools
2. Select
Interaction Builder
3. Enter
the page you want to test in the address box
4. Press
Enter or select the GO Button
5. Select
the test preview mode
6. Select
the styles button
7. View
how the page looks without style sheets
From the automated tester you can enable Checkpoint 3.3 and
when it scans it will do the work of identifying pages that need validation and
also find all pages that incorrectly use bold or italics.
3.4 Use relative rather than absolute units in markup
language attribute values and style sheet property values.
Disabilities Addressed by this CHECKPOINT
The following disabilities are addressed by this paragraph:
- Weak vision
- Aging Eyes
- Hardware limits such minimal resolution size
USING Relative VERSUS ABSOLUTE SIZING
Recently there has been much discussion surrounding this
topic. The argument has been that since browsers openly and easily allow for
the resizing of pages being viewed by the user that this checkpoint is no
longer valid.
Running a test of this in a current browser demonstrated
interesting results. While the sizing did work, (with essentially the same
results for Firefox, Opera, and Internet Explorer) the test failed from the perspective
of usability. The banking sites, online education sites and general sites were
at best not usable (in the sites tested) and because of their rich components sizing
was impracticable.
Testing your page for compliance to WCAG P2 3.4
It is easy to test your page for compliance to checkpoint 3.4.
Open your page in your favorite browser and modify the text size. For our steps
we will use Internet Explorer, simply follow these steps in IE 7:
1. Select
the Page Menu
2. Select
text Size
3. Change
the Text Size
4. Review
the page to see that all items of text resized properly
3.5 Use header elements to convey document structure and
use them according to specification
Disabilities Addressed by this CHECKPOINT
Separating structure and presentation is another way of
assuring that all assistive technologies will have an easier job of getting
content to the users of the specific assistive technology.
USING Section Headings
It is agreed throughout the development community that while
design elements can help users navigate a page it is still very important to
maintain a structure in your documents that use markup to represent that
structure. In HTML this would be the use of Headers to form the document
structure.
Testing your page for compliance to WCAG P2 3.5
It is easy to test your page for compliance to checkpoint 3.5.
Using a tool like AccVerify you can scan for the existence of headings and then
that headings are used properly.
3.6 Mark up lists and list items properly
Disabilities Addressed by this CHECKPOINT
Separating structure and presentation is another way of
assuring that all assistive technologies will have an easier job of getting
content to the users of the specific assistive technology.
USING LIST ELEMENTS AND ITEMS EFFECTIVELY
Continuing the topic of separating structure and
presentation, the LIST element should be used properly. It is notable that
compound numbers are much more effective than simple numbers. Remember that
lists are read by screen readers and the numbering perspective is then a
practice of reading the list aloud.
Testing your page for compliance to WCAG P2 3.6
It is easy to test your page for compliance to checkpoint
3.6. Using a tool like AccVerify you can scan for the existence of list
elements and then review to see that they are being used properly.
Example of a properly formed list that would read aloud the
numbers 1, 1.1, 2, 2.1
1. List
Item
1.1. List Item 1 sub 1
2. List
Item 2
2.1. List Item 2 sub 1
Example of a improperly formed list that would read aloud
the numbers 1, 1, 2 1
·
List Item
1. List Item 1 sub 1
·
List Item 2
1. List Item 2 sub 1
3.7 Mark up quotations. Do not use quotation markup for
formatting effects such as indentation.
Disabilities Addressed by this CHECKPOINT
Separating structure and presentation is another way of
assuring that all assistive technologies will have an easier job of getting
content to the users of the specific assistive technology.
USING QUOTATIONS
Whether you are using Q or BLOCKQUOTE it is imperative that
they only be used properly. This means that you must be using them only for
quotes and not for the purpose of indenting text. BLOCKQUOTE and Q are
structure items and should not be misused as misusing them only serves to
decrease clarity.
Testing your page for compliance to WCAG P2 3.7
It is easy to test your page for compliance to checkpoint 3.7.
Using a tool like AccVerify you can scan for the existence of Q or BLOCKQUOTES
and when you have found them you can validate proper use of the same.
5.3 Do not use tables for layout unless the table makes
sense when linearized. Otherwise, if the table does not make sense, provide an
alternative equivalent
Disabilities Addressed by this CHECKPOINT
Separating structure and presentation is another way of
assuring that all assistive technologies will have an easier job of getting
content to the users of the specific assistive technology.
USING TABLES for layout
It is a very strong argument that the use of tables for
layout should be avoided all together and violates AA Accessibility compliance.
The argument that is most often used is that WCAG forbids it in WCAG 1.0 P2. As
we can see in 5.3 it is not forbidden, however it must be done right.
Testing your page for compliance to WCAG P2 5.3
It is easy to test your page for compliance to checkpoint 5.3
AccVerify preview modes can walk you through the process. Here are the steps to
use the preview mode:
1. Open
AccVerify
2. Select
the Page you want to test
3. Select
the Files/Preview tab
4. Select
the [Preview] Button
5. Select
the [Linearize] Button
6. Review
the results
5.4 If a table is used for layout, do not use any
structural markup for the purpose of visual formatting.
Disabilities Addressed by this CHECKPOINT
Separating structure and presentation is another way of
assuring that all assistive technologies will have an easier job of getting
content to the users of the specific assistive technology.
USING TABLES for layout
It is a very strong argument that the use of tables for
layout should be avoided all together and violates AA Accessibility compliance.
The argument that is most often used is that WCAG forbids it in WCAG 1.0 P2.
As we can see in 5.4 it is not forbidden, however it must be done right.
Testing your page for compliance to WCAG P2 5.4
It is easy to test your page for compliance to checkpoint
5.4. AccVerify custom test cases are used to identify style or presentation
elements used within tables thus allowing you to automatically, via the
automated scan functions, fail all pages that do not comply.
6.4 for scripts and applets ensure that event handlers
are input device-independent.
Disabilities Addressed by this CHECKPOINT
Separating structure and presentation is another way of
assuring that all assistive technologies will have an easier job of getting
content to the users of the specific assistive technology.
USING EVENT HANDLERS
It is imperative that for both scripts and applets that the
event handlers used are coded to be device-independent event handlers and in
most cases application level event handlers such as “onfocus”, if you must use
device dependent event handlers cover for all devices possible.
An example would be using both onmousedown and onkeydown for
the event handle.
Testing your page for compliance to WCAG P2 6.4
It is easy to test your page for compliance to checkpoint
6.4. The use of AccVerify custom test cases is used to identify improper use of
event handlers. You can also utilize the out of the box test in the WCAG
priority two checkpoints that ships with the solution.
6.5 Ensure that dynamic content is accessible or provide
an alternative presentation or page.
Disabilities Addressed by this CHECKPOINT
This checkpoint addresses the visual and non visual needs as
well as the motion requirements of individual users. This includes but is not
limited to text transcripts and auditory presentations.
USING THE LINK ELEMENT
For 6.5 the Link element is a common method to provide an
alternative presentation. USER Agents that support the LINK element will load
the alternative document if a specific browser is designated as supporting the
alternative rendering.
Testing your page for compliance to WCAG P2 6.5
It is easy to test your page for compliance to checkpoint
6.5. The AccVerify Accessibility Checkpoints cover 6.5 specifically and by
default in the scanner settings. All pages that use the link rel with the
alternative attributed will be marked and reviewable.
7.2 Until user agents allow users to control blinking,
avoid causing content to blink
Disabilities Addressed by this CHECKPOINT
Photosensitive Epilepsy - A flickering and or flashing
screen may cause seizures.
USING screen flickering and flashing with scripts
This should be avoided.
Testing your page for compliance to WCAG P2 7.2
Validate all scripts do not allow flickering or flashing.
Users can create a custom test suite in AccVerify where you specify the test to
be against script and the keywords associated can be used to identify and fail
pages if necessary.
7.4 Until user agents provide the ability to stop the
refresh, do not create periodically auto-refreshing pages.
Disabilities Addressed by this CHECKPOINT
Automatic screen and page refresh can be very disorienting
to some users. In many cases it can prevent the completion of a task. This
impacts multiple disabilities.
USING AUTOMATED REFRESH
This should be avoided. But if used, it should be user
configurable and the user should be able to shut off the automatic refresh in
all cases.
Testing your page for compliance to WCAG P2 7.4
Using AccVerify and the automated scanner it is very easy to
scan an entire website for the use of the HTML Technique of html meta element
of type http-equiv with the attribute of refresh, If this is found the software
would fail the associated page.
7.5 Until user agents provide the ability to stop auto-redirect,
do not use markup to redirect pages automatically.
Disabilities Addressed by this CHECKPOINT
Automatic screen and page redirect can be very disorienting
to some users. In many cases it can prevent the completion of a task. This
impacts multiple disabilities.
USING REDIRECTS
All redirects should be configured to be performed server
side versus client side.
Testing your page for compliance to WCAG P2 7.5
Using AccVerify and the automated scanner it is very easy
create a custom test that will identify and flag all client side redirects as a
failure.
9.2 Ensure that any element that has its own interface
can be operated in a device-independent manner.
Disabilities Addressed by this CHECKPOINT
Users get to content by using a web user agent. The same
users MUST be able to interact with the document or web application rendered by
using input or output devices of their choice. Device independence is essential
as it maps to abilities regardless of what they are.
Testing your page for compliance to WCAG P2 9.2
This is a manual validation; however, the results achieved
are integrated by using the AccVerify Interview wizard for users of AccVerify.
9.3 for scripts specify logical event handlers rather
than device-dependent event handlers.
Disabilities Addressed by this CHECKPOINT
Users get to content by using a web user agent. The same
users MUST be able to interact with the document or web application rendered by
using input or output devices of their choice. Device independence is essential
as it maps to abilities regardless of what they are.
USING EVENT HANDLERS in scripts
It is imperative that script event handlers used are coded
to be device-independent event handlers and in most cases application level
event handlers such as “onfocus”. If you must use device dependent event
handlers cover for all devices possible.
An example would be using both onmousedown and onkeydown for
the event handler.
Testing your page for compliance to WCAG P2 9.3
It is easy to test your page for compliance to checkpoint
9.3 the use of AccVerify custom test cases be used to identify improper use of
event handlers or used the canned test in the WCAG priority two checkpoints
that ship with the solution.
10.1 until user agents allow users to turn off spawned
windows, do not cause pop-ups or other windows to appear and do not change the
current window without informing the user.
Disabilities Addressed by this checkpoint
The following disabilities are addressed by this paragraph:
- Blind
- Weak vision
- Inability to use mouse
- Motor-Control Challenges
USING POP-UPS
Using pop-ups can both be a distraction and a necessity. However,
if used; the pop-ups should be coded properly. One way to let the user know of
a pop-up is to add the title attribute that informs the user that the Link
opens in a new window.
One of the common ways to make a pop-up work is to assign
the target of “_blank”.
Testing your page for compliance to WCAG P2 10.1
One simple test from AccVerify will identify all pages in
your site that do not confirm to your stated accessibility policy. Simply
create a test that will check all links with the target set to _blank without a
title attribute that contains the text of “New Window”
11.1 Use W3C technologies when they are available and
appropriate for a task and use the latest versions when supported.
Disabilities Addressed by this CHECKPOINT
This is more of a general checkpoint that specifies if it is
a W3C technology it is more likely to have been reviewed for accessibility and
today this most likely is not true.
Testing your page for compliance to WCAG P2 11.1
If this is important to you compare to the list below taken
directly from the W3C Website. http://www.w3.org/TR/WCAG10-CORE-TECHS/#access-reviewed
Brief overview of current W3C technologies:
·
MathML for mathematical equations
·
HTML, XHTML, XML for structured documents
·
RDF for meta data
·
SMIL to create multimedia presentations
·
CSS and XSL to define style sheets
·
XSLT to create style transformations
·
PNG for graphics (although some are best expressed in JPG, a
non-w3c spec.
11.2 Avoid deprecated features of W3C technologies.
Disabilities Addressed by this Checkpoint
This is one of the W3C checkpoints that do not address a
specific ability. This checkpoint is more of a guide for developers. Avoid
deprecated elements and attributes as developers may cease in support of
capabilities.
Testing your page for compliance to WCAG P2 11.2
HiSoftware AccVerify ships with a complete test suite that can
be used to fail every page that uses deprecated features allowing for a swift
and simple repair.
12.3 Divide large blocks of information into more
manageable groups where natural and appropriate.
Disabilities Addressed by this Checkpoint
This is one of the W3C checkpoints that do not address a
specific ability. This checkpoint is more of a guide for developers. Content
developers should provide context and orientation of all information presented.
Testing your page for compliance to WCAG P2 12.3
Your organization can use AccVerify to create custom test
suites to match the organizational goals that you have set. This is true for
guidelines and goals related to headers, ULs, captions, field sets, or any
other methods of providing context and or orientation, etc.
12.2 Describe the purpose of frames and how frames relate
to each other if it is not obvious by frame titles alone.
Disabilities Addressed by this Checkpoint
This is one of the W3C checkpoints that do not address a
specific ability. This checkpoint is more of a guide for developers. Content
developers should provide context and orientation of all information presented.
Testing your page for compliance to WCAG P2 12.2
AccVerify has an automatic check built into the system to
validate that the Longdesc attribute is used as required.
13.1 Clearly identify the target of each link.
Disabilities Addressed by this Checkpoint
This is one of the W3C checkpoints that do not address a
specific ability. This checkpoint is more of a guide for developers. Content
developers should provide clear navigation mechanisms.
ASSIGNING LINK PHRASES
A common error of developers is to create links at the end
of a sentence with a meaningless phrase:
·
Click Here
·
More Information
·
Try it now
These would perhaps be fine if used only once on a page and
directly next to the text (but not for link handlers). Unfortunately most
developers that use click here do so wrongly. It is best to use real
information for the link and if needed add a title.
Testing your page for compliance to WCAG P2 13.1
AccVerify has an automatic check built into the system to
validate that the navigation links do not use the same text for differing
targets and that the navigation links do not use identified problematic terms.
13.2 Provide metadata to add semantic information to
pages and sites.
Disabilities Addressed by this Checkpoint
This is one of the W3C checkpoints that do not address a
specific ability. This checkpoint is more of a guide for developers. Content
developers should provide clear navigation mechanisms.
ASSIGNING METADATA
The Title is an important metadata element and is essential
for navigation. In addition a product like HiSoftware TagGen can be used to
enter page keywords and descriptions to help facilitate clear navigation.
Testing your page for compliance to WCAG P2 13.2
AccVerify has an automatic check built into the system to
validate that the title of a page is used once only per site to facilitate
clear navigation. In addition there are checks that can be configured to test
metadata
13.3 Provide information about the general layout of a
site (e.g., a site map or table of contents).
13.4 Use navigation mechanisms in a consistent manner.
Disabilities Addressed by this Checkpoint
This is one of the W3C checkpoints that do not address a
specific ability. This checkpoint is more of a guide for developers. Content
developers should provide clear navigation mechanisms.
Creating a Site MAP
Tools like HiSoftware’s Link Validation utility can help you
create a site map for your web property
Testing your page for compliance to WCAG P2 13.3 and 13.4
AccVerify has a built in check that allows you to specify a
link to your sitemap or table of contents. If this link is not found on any
page it will fail that page as required by the checkpoint. This method also
satisfies 13.4
In this chapter
·
Introduction
to WCAG 2.0
·
Discussion
of Differences between 1.0 and 2.0
·
What is new
in 2.0
·
How does
WCAG 1.0 map to WCAG 2.0
The Web Content Accessibility Guidelines are in the process
of being updated to a new version. Version 2.0 has generated a very interesting
worldwide dialogue regarding what it “should and should not be.” It has
garnished much support and some companies are now building to what they believe
will be the final WCAG 2.0 standard. While it is sensible to build content for
the standard that will become accepted in the future, it is nonetheless
important to consider both backward and forward compatibility. Even once the
WCAG 2.0 guidelines are implemented, there may be some organizational or
statutory lag behind in the adoption of the new guidelines. For that reason, it
will be important to understand both sets of guidelines. Because version 1.0 of
the Web Content Accessibility Guidelines were drafted in the 1990’s they were
based on typical Web content of that time. With the rapidly changing Internet
environment there has been a great push for rich and highly dynamic interactive
content, that was either unavailable or in very limited use at the time WCAG
1.0 was issued. The WCAG 2.0 guidelines attempt to better address the Web
technologies of today and the future. They also focus on testability and test
cases. At the time of the writing of this book WCAG 2.0 is still draft and this
means that WCAG 1.0 supersedes 2.0 in every case. In this chapter we will begin
a discussion on WCAG 2.0 but in the end we will give pointers on where to get
more information.
The numbering systems have changed as have the success
criteria. WCAG 1.0 utilizes a structure of Priority One through three and in
WCAG 2.0 has levels of Success Criteria, Levels One through three. This allows
you to be rated as; A, AA, or AAA levels of conformance.
For Priority One versus Level One there is only one new
item, Guideline 2.5.1. This guideline states that if there is an input error
then the error must be identified and described to the user as text.
For Priority Two versus Level Two there are several new
items. Guidelines 1.3, 1.4, 2.4, and 2.5 all have new values. For more
information on compliance please refer to the W3C Web Site the WCAG 2.0
Guidelines.
http://www.w3.org/TR/2006/WD-WCAG20-20060427/Overview.html#contents
. The following information is taken directly from the W3C Web site Appendix D:
Comparison of WCAG 1.0 checkpoints to WCAG 2.0
“Guideline 1.3
1.3.4 Information that is conveyed
by variations in presentation of text is also conveyed in text, or the
variations in presentation of text can be programmatically determined. (Level
2)
1.3.5 Information required to
understand and operate content does not rely on shape, size, visual location,
or orientation of components. (Level 2)
Guideline 1.4
1.4.2 A mechanism is available to
turn off background audio that plays automatically, without requiring the user
to turn off all audio. (Level 2)
Guideline 2.4
2.4.3 Web units have titles. (Level
2)
Guideline 2.5
2.5.2 If an input error is detected
and suggestions for correction are known and can be provided without
jeopardizing the security or purpose of the content, the suggestions are
provided to the user. (Level 2)
2.5.3 For forms that cause legal or
financial transactions to occur, that modify or delete data in data storage
systems, or that submit test responses, at least one of the following is true:
(Level 2)
1. Actions
are reversible.
2. Actions
are checked for input errors before going on to the next step in the process.
3. The
user is able to review and confirm or correct information before submitting
it.” W3C, Comparison of WCAG 1.0 checkpoints to
WCAG 2.0. Retrieved February 18, 2008, from W3C Web site: http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixD.html
From the resource and the links provided above it is clear
that the items in WCAG 1.0 P1 and P2 are nearly identical to WCAG 2.0 L1 and
L2. The most interesting part is perhaps the fact that WCAG 2.0 focuses more on
the ability to test for conformance making it easier for developers to test for
compliance, much in the same way US Section 508 was more geared toward the
ability to validate conformance.
It would make sense for you to start reading, and the best
place to start is the W3C published mappings from WCAG 1.0 to 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixD.html
Additional Reading on the W3C:
Essential Components of Web Accessibility
http://www.w3.org/WAI/intro/components
Overview of WCAG 2.0 Documents
http://www.w3.org/WAI/intro/wcag20
Understanding WCAG 2.0
http://www.w3.org/TR/UNDERSTANDING-WCAG20/
Techniques for WCAG 2.0
http://www.w3.org/TR/WCAG20-TECHS/
It is important that you wait for this standard to be
finalized before coding to it. A good example was the concept of baselines.
The Document about baselines is a perfect case in point. http://www.w3.org/WAI/WCAG20/baseline/
. In the draft process this was considered to be important. It was rejected by
the community; therefore any work done would have been wasted. If you go to the
link above you will see:
“[OUTDATED DOCUMENT] About Baselines and WCAG 2.0”
Because of this it is recommended that you prepare but not
move to WCAG 2.0 until it is finalized and you also may want to consider
backward compatibility.
In this chapter
·
Introduction
to common accessibility errors
·
Introduction
to quality assurance
·
Introduction
to accessibility testing with software tools
·
Using
Verification, Repair, and Monitoring tools with explanations of what they can
and cannot do
·
Accessibility
testing and content management / current test architectures
Applying accessibility testing to your current Web site
quality assurance practices is the easiest way to ensure an accessible site.
This chapter will introduce you to common errors and the quality assurance
process.
The accessibility guidelines and standards provide an
excellent guide for making your Web site accessible. Whether you are following
W3C Priority One Guidelines or 508 Standards it is important to understand the
most common errors that Web developers make when developing a Web site. This is
important from a testing perspective because if you understand the most
frequent errors you can develop a proper testing methodology and plan. Common
errors are divided into two groups for the purpose of this book, Design errors
and Guideline / Standards errors.
Note: Guideline refers to the
W3C/WCAG guidelines. The guidelines are a proposal and not a standard that Web
site developers must follow if they want to achieve accessibility. Standards
refer to the Section 508 Electronic Information Technology Accessibility
Standards; Final Rule. (Actual US Federal Standards that government sites
are required to meet.)
The most common design errors that impact accessibility of a
Web site are:
- Use of Frames
- Overuse of java based menu systems that might look
impressive but tend to be overwhelming
- Assumption that placing forms and field descriptions in
tables makes the form more usable
The most common accessibility errors that prevent a site
from being utilized effectively by peoples with disabilities are:
- Use of Frames that are not easily navigated
- Not using alternative text for non-text based elements
o Objects
- And other non-text elements
- Using priority two or three recommendations to try to
satisfy 508 or W3C priority one rules
- Not providing a site map or contents
- Non-accessible Image maps
Sites that can address the items listed above will find
themselves close to compliance or in compliance. This will have a profound
impact on the overall accessibility of Internet content.
Quality Assurance for Web sites is an essential activity for
businesses or organizations that develop content or Web site applications to be
used by others. It is safe to assume that any organization that has a Web site
for public or internal use has in place some sort of Web site quality assurance
practices. This internal QA group serves as the consumer’s in-house representative.
When performing their tasks the QA group looks at the Web site from the
perspective of the Web site visitor.
Like Software testing Web site testing starts with the
standards and requirements of the product or Web site and its functionality.
This means that if a Web site is initially designed to perform a set function
or to provide information in a specific format then it must complete that task
as specified.
The Objectives of Web Site Testing:
- The testing of a Web site combines both content editing
and functionality testing with the intent of finding errors.
- The tester should strive to develop test cases that have
the highest likelihood of producing errors. Remember a successful test is
one that uncovers errors. (e.g. Because an object has been developed to
function its best under Internet Explorer, a good test case would be to
test it on all other browsers to assure the same results are obtained.)
In the case of accessibility there would be a test plan in
place designed to ensure effective accessibility error detection. The task of
error detection does not end with the initial “Basic” test. We must look
further then the basic requirements.
Types of tests that could apply to Web site Accessibility
Testing:
- Condition Testing - This test type is best defined as a
true/false test. For Example, it may be a test of a specific operating
system (“OS”), for which the Condition being tested. Another example might
be testing performance through different Web browsers. Condition testing
is generally relevant for the testing of dynamic data and not static web
sites.
- Data Flow Testing - Based on the flow of inputs to a Web
site application, different screens and general content will be presented.
This output to the user needs to be verified and validated for compliance
to the accessibility standards. Data Flow testing is again best suited for
dynamic web sites. This is more than likely to be used in a Web based
application, (I.e. an online reservation system.)
- Boundry - Boundary testing can be defined as testing the
limits of specific inputs. As with the previous test type, a boundary test
is most frequently designed for dynamic sites where specific user inputs,
OS, or User Agents could have a direct impact on the content delivered.
- Verification – Verification is the process of determining
that you have met your organizations requirements and or standards for the
Web site as defined. (In the case of Accessibility this may be Section 508
or W3C Priority one). Note: This test type is designed to assure that
requirements are met- not if they were right in the first place.
- Validation – This test process is a check for the initial
requirements. It looks at the requirements and then the final Web site to
determine that while the desired responses have been produced, in response
to the test, the requirements have also met their objectives. For example,
an organization may have the Web site reviewed by an inside or outside
group to determine usability of the site even though it complies with the
accessibility rules. This assures not only compliance but usability of the
end product.
- Change Testing – Change testing for Web sites as with
software quality assurance is very important. Whether a site is dynamic or
static the content will be changed or content will be added. Upon changes
a page or site need to be retested. Because of the nature of authoring and
Content Management tools it is possible that one change can create
countless accessibility errors. For example, in an authoring tool, adding
a link to an image map may clear all other alt text for the entire image
map. In a content management system, changing one template could make the
whole site inaccessible. Alternatively, the modification or removal of an
image asset could make one or many pages inaccessible.
One of the most important steps you could perform is to beta
test your Web site. This means to test you page or site before going live into
production. Whether you are a large organization or a small company you should
make the time to do this. Once you have completed the development of the page
or site, and once you have completed accessibility testing you should have the
product beta tested.
This process has an outside individual look at the page to
see if it performs like it was designed to. This user is not part of the
products or sites qa or development team, and does not necessarily need to be a
tester. Once the product / Web site is beta tested it should then be released
to production.
Developers or auditors of Web sites, at key checkpoints in
an overall process, will determine whether objectives and or requirements are
being met by testing. Accessibility testing (commonly referred to as
verification) has two main components - automated and visual. In order to
complete a successful audit or test of content you must understand how you can
implement a successful test plan.
Automated testing is
accomplished with either a Web site crawler (Agent) or a file scanner. The
agent will imitate a user agent, obtain the content for the Web pages, and then
perform an evaluation of the content to see if it complies with the guidelines.
Visual testing is used for
verifying guideline checkpoints that do not have the structure or
predictability available to allow for automated pass or fail detection.
A preferred solution would combine the automated testing and
the visual testing, thereby only requiring a visual verification of pages where
elements that require visual verification were found. Small organization with
predominantly static content will find the task of creating an accessible Web
site to be relatively simple. Mid to large sized organization will find the
task to be a little more challenging.
When testing site content there are two instances the
company should address. The first instance is content creation. The Second is
existing site content. As with any development effort, Web content or software,
it is always less costly to find and correct errors before they make it to the
production environment (actually become published). This means that a company
needs to perform testing at both page and site level.
Page
The author who develops the actual
page should test it for compliance before publishing the content. This should
become a final part of any process that deals with the publishing of electronic
content.
Site
From a site wide perspective
companies should implement unattended services, either hosted or placed on
their internal servers that will constantly monitor Web sites or portions of
the Web sites and alert responsible parties if there is a problem that brings
them out of compliance.
It is becoming more common for Web content to be dynamically
generated delivered via content management or publishing servers. In this case
you have to consider a different type of testing, template testing. Dynamic
sites use templates to deliver content. It is important in this case to test
all templates before they are placed into production.
For more information on Accessibility and Dynamic Content
please see chapter Five. Chapter five goes into detail on Dynamic Content and
also shows how an error in templates can create catastrophic Accessibility
errors on your Web site.
It is becoming more common for Web site Authors/managers to
implement the use of accessibility verification, remediation and repair tools
to assure site accessibility. These solutions can assist in decreasing IT
overhead and human resources for development projects. This section will deal
with the types of tools available and how they should be applied to your
testing process.
An accessibility verification tool is a software solution or
a hosted service solution that allows you to test a page that you are working
on or a group of pages of a (Logical or Physical) Web site for compliance with
the accessibility standards. This technology can be instrumental in developing
accessible content quickly and at a greatly decreased cost. The solutions are
available in many different forms:
- Desktop Software – Runs on a client desktop and
runs with or without user interaction. Desktop software is generally
suited for testing of smaller workgroup sites Web based and local pages.
It is generally not used to disseminate information to a team. An
example of a desktop software product would be HiSoftware’s AccVerify
Software
- Server Software – Server based solutions generally
run without requiring any user intervention except for initial
configuration. Additionally, once configured or for initial configuration
there is general a “Web-Based” interface so that after installation there
is no requirement for access to the console of the server.
- Hosted Services – A Hosted service is similar to
the Server software; the main difference is that there is no hardware
requirement since the server software is installed and maintained and the
service providers’ facilities.
As part of your evaluation, look for solutions that provide
example files demonstrating all potential accessibility issues that can be
tested. This will aid in ensuring that the checks implemented comply with the
standards.
Verification software should also support the following
types of verification:
- FTP – Anonymous File Transfer Protocol
- FTP Authentication - File Transfer Protocol that
requires a user be authenticated with a username/password pair.
- HTTP – A User agent capable of issuing requests and
receiving responses from an anonymous web server.
- HTTPS - A User agent capable of issuing requests
and receiving responses from a web server that supports the Secure Socket
Layer.
- HTTP(s) Authentication - A User agent capable of
issuing requests and receiving responses from a web server that supports
http authentication and optionally the Secure Socket Layer.
- Local File Scanning – The ability to scan a local
file system and identify and verify all documents that match the
configured web based document extensions.
- Local File Selection – The ability to select local
files from a user’s computer or server.
- Browser Emulation (Essential for Dynamic Sites) –
Web content may differ based on the site programmer’s requirements coded
for each agent.
Therefore, the software should have
the ability to interact with a Web server or test a Web server, and in doing so
identify the user agent as an agent other than it in order to test how the
server would react for each agent
- Firewall support – The ability to send requests and
receive responses via a corporate firewall.
- For training reasons there should be support for historical
viewing of your accessibility status
If you want a quick and free trial of an accessibility tool
that runs around the clock visit:
http://www.accessibilitywatch.com/
This site allows a free verification of five pages
immediately. E-mail will be sent with links to reports of the accessibility
status of your site!
Remediation tools are always controversial to HTML
developers. The reason is the author fears that the tools will invalidate their
HTML by performing bad modifications. However, repair tools can be valuable in
the management of Web site accessibility.
- The remediation solution you choose should be able to work
with files that are developed or stored on Windows, Unix (Linux), or Apple
based systems.
- The remediation system should include full support for
spell checking any alternative text representations entered to comply with
accessibility.
- The remediation system should allow Web teams to
collaborate on repairs for single or multiple pages.
- The remediation tool should learn the meanings of input
elements, objects, and any element requiring alternative text or element
content.
- The remediation tool should allow values to be edited in a
library environment outside of the repair process.
- The remediation tool should allow for automated repairs
where possible.
If a repair (remediation) tool is implemented properly it
can prove to be essential in the process of making a site accessible.
Additionally, a good repair tool decreases the training requirement for your
Web team as well as decreasing the likelihood of errors.
Remember that because Web site content is dynamic - it is by
nature always changing. That means that an important piece of any accessibility
strategy is a solution that will let you ensure that your sites remain in
compliance on an ongoing basis. From a site wide perspective companies should
implement unattended services either hosted or placed on their internal servers
that will, once configured, constantly monitor Web sites or portions of the Web
sites and alert responsible parties if there is a problem that brings them out
of compliance.
An automated testing tool can be used to test your site or
groups of documents in an unattended manner once they are configured. It is
very important to remember that “NO” tool alone can validate the absolute
accessibility of your web site.
However a good tool can identify a majority of what needs to
be verified visually. Additionally a good tool will let you know what pages do
not need to be verified visually, based on the absence of elements that require
visual verification. Remember: You will still need to assure that all visual
checkpoints identified by the solution are accessible.
As with any testing requirement for Web-based content you
will have choices to make when selecting your accessibility testing solution.
You should evaluate the solution you choose to make sure that it can complete
the task that you need completed. In addition to this you should verify that
the tool has:
A Common Design – Decreases
the level of training required to implement the solution.
Complete Program Help & User Documentation
– Regardless of the tool there will be some time required to come up to speed
on the use of the product. When you evaluate a tool make sure that complete
documentation is available.
The capability to automate – Your testing
tool should allow for client side or server side automation. This is important
because the process of testing Accessibility can become resource intensive if
the number of pages is greater than a few hundred. Additionally the solution
should allow you to test pages without user interaction.
The Following Items can represent Automation
capabilities:
·
A Published, Public, and Documented Applications Programmers
Interface (API)
·
Scripting Support – The Ability to create and run test scripts.
·
A Scheduling Subsystem (Generally with Server Side Products)
·
Integration with the Operating Systems Scheduling Sub-System
(e.g. The Windows Task Scheduler)
·
Automated Accessibility Alerts
It is clear that with training and content engineering you
can have a positive impact on the overall accessibility of your Web site. Your
content management system (if applicable) is a good starting point.
By using a repair or verification tool that supports
automation or by using a server-based tool as part of the content preparation,
you can quickly and automatically prevent inaccessible content from being
published. You can also use verification tools to assure that templates that
are used to display data are also accessible. Accessibility verification and
repair can be built into the pre-publishing quality assurance checks and
balances of your content management system.
Most organizations already have in-place a Web site quality
assurance testing process. Additionally this process may include the use of
generalized or specialized tools and/or services.
Accessibility
testing could be retrofitted into this process if the same quality assurance
team will be responsible for accessibility testing or if the same test
management system is being used.
This means that if you are currently using site-testing
tools, it is important that your accessibility-testing tool can be integrated
with the testing application via its API or via the accessibility testing
solution’s API.
Testing tools, which incorporate accessibility verification,
will allow you to implement site assessments, accessibility project plans,
testing requirements, test management, and defect assignment and tracking.
API is the Acronym for Application Programmers Interface. If
a product has an API it means that some or all of its functions can be accessed
programmatically. This allows for automation programming and for integration
with your existing systems or processes.
6. Developing a Strategy for Accessibility
Compliance
In this chapter
·
Performing a
site assessment
·
Setting
goals
·
Setting
design guidelines
·
Training
developers
·
Scheduling
your site retrofitting project
·
Introduction
to unit testing
·
Introduction
to conformance testing
·
Introduction
to compatibility testing
·
Introduction
to accessibility maintenance
·
A
step-by-step approach to accessible content
·
Introduction
to Intranets
·
Introduction
to accessibility planning for Intranets
The practice of designing accessible Web sites is not new,
however, the adoption of this concept by the mainstream is! This new practice
can produce new and significant training requirements.
Organizations have been pushing the design elements of their
Web sites for a while, attempting to develop the richest and most appealing Web
content possible. Accessibility now has to be retrofitted into most sites as
organizations become aware that they have left behind over 50 million potential
customers or site content viewers. While this was not the original intent of
the designers it is a problem that must be addressed.
In the previous chapters we have clearly defined
accessibility guidelines and those whom they impact. After reading the previous
sections you should have a better understanding of the level of effort required
to build a Web site that is accessible by everyone.
An accessibility strategy will provide your organization
with the ability to view accessibility from a project management perspective.
This will enable your organization to:
- Allocate resources appropriately
- Track site progress
- Educate employees
- Identify problem areas
- Integrate accessibility into quality assurance and content
delivery processes
- Keep a historical view of your Web site accessibility work
Most corporations and government agencies that have a Web
presence have Web content or application development teams. Many of these
organizations have multiple teams each with specific responsibilities across
different content and design aspects of any given site or application. Each of
these teams will need to be responsible for their team’s accessibility concerns
and requirements. For the purposes of this book these teams will be categorized
into five main groups:
A content development team
consists of the people who generate the actual content that will be presented
by the site. Additionally they most likely are responsible for placing content
and any graphics and/or objects together on the core site. In this definition,
content refers to text / writing not the graphics or functional components of
the site. This applies to dynamic or static content.
A Multimedia development team is
responsible for the creation of rich content. Some types of rich content are:
- PowerPoint Slide Shows
- Streaming Audio or Audio Files
- Video and Streaming Video
- Flash Presentations
A Layout and Design team is
responsible for the creation of the overall site navigation and/or layout.
A site management team is
responsible for the core architecture of the Web site and its compliance to the
organizations standards.
A graphics development team is
responsible for all graphical representations or imagery for the site.
These groups are logical breakdowns of what is required to
create a Web based information portal. Depending on your organizational
structure there may be crossover roles and responsibilities between Web groups
and designers.
As with any project make sure you put the right leadership
team in place. Your Accessibility project team should include individuals from
every group that contributes to the development and maintenance of your Web
site. In the average organization the following groups would most likely be
represented:
- Marketing – For their knowledge of who uses the
site and for their knowledge of site usage statistics.
- Development – For their knowledge of what skills
and technologies will be needed to complete the task.
- Public relations – Involve your Public Relations
team to determine whether or not the accessibility effort should be made
public.
- End Users – From internal users to an outside beta
tester group, actual users will help to make any accessibility project be
successful.
- Executive management – Corporate or Executive
representation on the team will help to keep the project funded.
- Operations – This group is generally responsible
for overall Web site performance and testing. This group will be critical
in the development of a long term site accessibility strategy.
- Professional development / training – This group
should be part of the project from the beginning so they can better
understand training requirements.
The level of participation for each group will vary;
however, they all will play an important role in the project.
The following are the four basic phases of developing and
maintaing an accessible Web site:
- Developing a plan – Performing a site assessment,
setting your organizations goals, and setting design guidelines and
standards.
- Implementing your guidelines – Training developers
and retrofitting current content. All new content development should be
performed based on your organizations new guidelines and standards.
- Accessibility testing – Complete testing to assure
that you have complied with your new guidelines and standards.
- Accessibility maintenance – Evaluate results;
automate verification of accessibility guidelines and standards.
It is highly recommended that organizations complete each of
the above phases to assure that organizations goals for Web site accessibility
are achieved. This phased approach is a very basic strategy based on fundamentals.
Your organization may require a more comprehensive strategy or a simpler
strategy. The process of planning a project could fill multiple texts- this
process represents the need for a real plan and serves as an introduction to
those individuals who have not worked within a formal project process in the
past.
For
example: An organization may have a terrific plan, create guidelines, do
initial testing but never perform the maintenance step. In this example a site
could return to an inaccessible state very quickly.
For a small Web site the assessment may be managed by
looking at each page to see where there are flaws. For larger sites, with more
than several pages of content, this method becomes cumbersome, and even
unmanageable. The use of an automated assessment tool is recommended.
The first step of any assessment is to determine the overall
accessibility condition of your Web site. Using readily available accessibility
assessment tools organizations can receive an instant snapshot of their Web
sites accessibility.
Image 3.1 – Graphical overview of a sites accessibility
standard compliance produced by AccVerify Professional.
An assessment tool can further show development team’s
important information about which accessibility rules are being violated.
Image 3.2 – Graphical overview
of a sites accessibility standard compliance down to exact detail on where
errors exist produced by AccVerify Professional.
Regardless of the tool used, it is important to get a valid
assessment, so that the development or management teams will be able to
determine the scope and nature of the work that will be required by the team
from a remediation perspective, as well as how many pages in the site will
require visual verification.
Image 3.3 – Graphical overview
of the percent of site pages that will require a visual overview to assure
compliance of accessibility standards, produced by AccVerify Professional.
In order to properly allocate company resources
organizations will also need an overview of the individual visual verification
required.
3.4
– Graphical overview of the actual elements in your site that require visual
verification to assure compliance of accessibility standards, produced by
AccVerify Professional.
When considering accessibility, it is important to
understand how site development teams use Web elements. Your assessment tool
should provide you with the following information:
With the following information organizations can adequately
assign tasks required to make the accessibility project successful.
The image summary of a Web site provides an immediate view
of how many references to images exist and how many do not comply with the W3C
or Section 508 Guidelines. In the example below, ten of the image references do
not comply with the guidelines.
Image Summary
Images: 13
Images without Alt attribute: 10
Images with Alt attribute: 3
Images with blank Alt attribute: 0
Images with null Alt attribute: 0
Image Counts by file extension:
Image File Extension Count
.gif 12
.jpg 1
The form summary of a Web site provides an immediate view of
how many forms exist as well as how many do not comply with the W3C or Section
508 Guidelines. In the example below, one of the Form Input Image elements does
not have alternative text.
Form Summary
Forms: 3
Forms with Labeled Controls: 0
Forms with Inputs using the Alt attribute: 0
Forms without Input elements: 0
Forms with Input Images not using the Alt attribute: 1
Forms without any use of
TabIndex: 3
Forms without any use of AccessKey: 3
The frame summary of a Web site provides an immediate view of how many
frames exist and of those how many do not comply with the W3C or Section 508
Guidelines. In the example below, none of the frames are in compliance with the
W3C and Section 508 Guidelines.
Frame Summary
Frames: 3
Frames without Title Attribute: 3
IFrames: 1
IFrames without element content: 1
The script summary of a Web site provides an immediate view
of how many script elements exist and of those how many do not comply with the
W3C or Section 508 Guidelines.
Script Summary
Script Elements: 2
Script Elements without NOSCRIPT: 2
The link summary of a Web site provides immediate views of
how many links are found containing the content “Click Here” or that contain
links to external documents that must be accessible or must comply with
accessibility guidelines.
Link Summary
Links with the phrase "Click Here"
in the link text: 0
Links to DOC files: 0
Links to MP3 files: 0
Links to MPG files: 0
Links to PDF files: 0
Links to PPT files: 0
Links to SWF files: 0
Links to XLS files: 0
These Web site summaries provide valuable information on compliance, or lack
thereof, for these essential design and/or interactive content elements.
Table Summary
Tables: 8
Tables with Summary attribute: 0
Tables with Caption: 0
Tables with Summary and Caption: 0
Tables with ID attribute: 8
Tables with Cells with ID attribute: 0
Tables with Cells that use Scope: 0
Data Tables: 7
Object Summary
Objects: 6
Objects without element content: 4
Applet Summary
Applets: 1
Applets without either the Alt attribute or element content: 1
Setting formal goals for accessibility compliance within
your organization is critical to the project success. The goals portion of your
project depends heavily on:
- The level of accessibility that you want to accomplish
- The current accessibility based on your assessment
- Defining training requirements based on the assessment
- Company resources available for the project
The level of accessibility compliance that is highly
recommended for all organizations is W3C Priority One and US Section 508. This
is an achievable goal and it will allow organizations to satisfy both US and
international guidelines. The other guidelines and/or recommendations available
today are not as widely accepted. It would be unwise to set organizational
goals higher until the expanded recommendations become more widely accepted.
Using the Assessment
Once you have a valid Web site accessibility assessment you
can begin to map the steps that will be required to make your site accessible.
This should begin with the training and education of the specific development
teams responsible for your entire Web content.
Content Development
If content development is dynamic
in nature, then it may be that a high percentage of content delivery methods
need to be made accessible, which will require the training of developers in
these methodologies. Developers will need to be trained in the creation and
testing of accessible templates, as well as accessible data that will populate
the templates on the end-user queries. For example, in the case of a product
catalog, a development team may need to automate the entry of alt text for
images displayed. Dynamic site developers need to be trained about all
accessibility concerns based on current development practice. Training should
also be provided to match technology updates and changes.
Multimedia Development
The use of multimedia for your Web
content should be carefully assessed as significant development time may be
required to implement accessibility. The training regiment should educate
multimedia developers in the accessibility issues associated with multimedia
Web elements, and should review tools and technologies that are available to
address or remediate these issues.
Site Layout and Design
Accessibility should become an
element that is part of every step of the Web site design process. The
assessment is the first level of training and going forward you may wish to
assign a member of the team to validate the accessibility of any proposed
design modifications.
Site Management
Site managers, who currently deal
with site flaws and errors, need to be trained on the accessibility
requirements. Accessibility testing should be implemented as part of the
Quality Assurance practices that already exist within organizations. Developing
and assuring accessible content prior to publication, as well as monitoring of
live Web sites can assist site managers in assuring that their sites are
accessible. Verification of compliance will be most effective if it is
incorporated into the standard organizational operating procedures and
regiment.
Graphics Development
Graphic developers need to be
trained on the accessibility requirements for graphical content. Training on
how to write text equivalents and deliver a base text equivalent with every
image should be provided.
With the accessibility goals and guidelines developed the
next phase of the project begins. In this phase developers and quality
assurance teams will receive training and the process of retrofitting the
company Web site will begin. As policy, companies should either issue a moratorium
on all new Web site development or set standards to assure that all new pages,
templates, and content is developed in compliance with the new standards.
Although most organizations have addressed at least some
accessibility issues in their Web content, others have addressed none, and few
have addressed all. With this in mind organizations must first make an
assessment of what is being done right and what is not being developed so that
it is accessible.
The Accessibility assessment is the most important phase of
determining a company’s accessibility strategy. If you are not sure about the
problem and its size you will not be able to provide the proper resources and
planning necessary to come up with a solution.
The site assessment allows for developing project goals.
Once a company has a project goals defined it is easy to determine what project
steps are required, milestones that will be achieved, and what the plan will
require. In determining resources consider several factors, which determine the
actual number of resources that will be required for the project.
- Total amount of content or the number of static pages
- Number of templates for dynamic content
- Time required to fix one page or template (in hours)
- Growth of Web site (How many new pages are added each week
or month)
- Total resources available to the project
- Priority of project
- Project start date
- Required project completion date
The analysis of the items listed above will allow common
project management systems to determine the number of resources required. If
your company does not use a project management system perform the following
calculation:
A+B*C
= total hours required for site remediation
H-G=
total days allotted for the project
Base
an average work day on six (6) hours then divide total hours by six (6) to come
up with number of resource days required to complete the project.
For example: If 40 resource
days are required to complete the project and if you only have 20 actual days
to complete the project. Divide the resource days (40) by Requirement days (20)
to come up with the number of resources required. In this example the number of
resources required to complete the project on time would be two.
Once the project is clearly defined and resources are
allocated a company is ready to begin the accessibility remediation project.
The testing section of the phased approach applies two
distinct testing types. “Developer” and “User” testing.
The developer is responsible for following the
guidelines and assuring that templates and/or static pages comply with
Accessibility Guidelines before they are delivered to final Quality Assurance
or User testing. In the software testing world the equivalent would be Unit or
“White Box” testing.
The user testing is normally the responsibility of
the quality assurance team. This team can be a formal testing team or for
smaller organizations, simply another developer that is trained in testing web
pages. This team is responsible for conformance testing and compatibility
testing.
Developers should test their work utilizing an accessibility
checklist, either manually or automatically generated that allows them to
verify that every page or template produces accessible output. For this phase
we recommend working with testing technologies that allow a developer to test
the page or template during the development process. It is important that the
tool provide both detailed error reports and page checklist reports. Remember,
this effort should be formalized, the cost of fixing errors found after
delivery to quality assurance or production will cost from three to five times
more to correct.
Conformance testing verifies that your site, page or
template implementation conforms to accessibility standards and/or guidelines.
As with unit testing it is recommended that you use automated testing tools to
more effectively determine your Web sites compliance.
Compatibility testing assures compatibility of a Web based
application or Web site when viewed by different browsers, and operating
systems. Although compatibility testing can be performed manually, we recommend
that an automated testing tool be used to handle this stage of testing. It is
important that the tool provides the capability of using test configurations
and scripts to minimize the number of resource hours required for this testing.
The quality assurance team should also be responsible for
the verification of Web site content presentation via assistive technology. In
this phase a tester will actually test the page against assistive technologies
to assure that the true meaning of the content is clearly communicated and/or
presented to the site visitor.
For Example:
- Use the IBM Home Page Reader to review a site for
accessibility for those with sight related disability.
- Print your page out on a black and white printer to assure
compliance to guidelines related to the use of color.
Once the previous phases have been completed a plan should
be in place that provides for ongoing testing and development to assure
compliance with organizational guidelines and standards. The previous chapter
introduced accessibility monitoring. In the maintenance phase you will want to
institute site monitoring and:
- Continued training – The process of continued professional
development for site developers and quality assurance testers.
- Defect reporting and remediation procedures
The phased approach offers the best opportunity for Web site
compliance to accessibility guidelines and standards. Companies can look
forward to the continued accessibility of their Web content once they develop
the above disciplines.
An Intranet is a private network of computers. This network
can be utilized by authorized users of the network owner. Intranets are
utilized for internal distribution of information, communication, and/or
application sharing.
The most common uses of Intranets are:
- Information distribution and publishing
- Corporate communications
- Corporate management
- Corporate Application sharing
One of the general goals of the Intranet is to decrease
individual workstation and maintenance cost while increasing knowledge sharing.
This task has clearly been accomplished by many organizations.
Internets and Intranets have many common characteristics and
are based on identical technologies. The main difference is that a company owns
their Intranet while the Internet is publicly available. Some companies expand
Intranet capabilities by making portions of their resources available through
the Internet in a secure manner; this is referred to as an Extranet. Intranet
and Extranet site access is generally controlled by a user access security
scheme.
The previous sections of this book have covered the
accessibility issues, standards, and challenges. However, the book would be
incomplete if it did not cover Intranet accessibility. Companies that are
committed to developing accessible information and providing accessible
solutions for their employees to complete their tasks must make their
Intranets accessible.
Intranets almost always have more content and applications
then an Internet site. The task of making an Intranet site accessible can seem
impossible! In fact it is easier. The reason that it is easier to correct
accessibility issues for Intranets is because they are private. This allows
companies to have greater control over the project. Follow the same phased
approach that was described above to develop your Intranet plan and goals.
Intranet accessibility projects should be divided and ordered by priority as
follows:
- Develop an Intranet accessibility policy
- Make accessible all Intranet applications that employees
require to communicate with other employees.
- Make accessible all information repositories required for
employees to perform their job.
- Retrofit all other Intranet documents and applications.
The above tasks should be planned. Organizations should set
realistic goals and develop metrics that can be used to measure their success.
It is highly recommended that you make this process of Intranet accessibility a
very public process. Ask for and accept feedback from your employees.
A Fortune 100 site, recently requested a review by
HiSoftware’s AccessibilityWATCH. The site had a failure ration of over 96% of
all their pages. When the company was presented with this information, it
appeared to be an overwhelming remediation task and one that they did not
believe the company would approve.
Using the Assessment technologies mentioned above the
company was able to separate the errors and by doing this some interesting
information was discovered.
- If all Images were fixed 62% of all pages would pass the
accessibility requirements.
- If all input elements were fixed then 72% of all pages
would pass
- If all objects and applets were fixed then 77% of all
pages would pass
- If all Frame pages were fixed then 92% of all pages would
pass
Knowing this information provided them with the belief that
the problem was not as large or overwhelming as it had initially seemed and
that they could, over time, provide a project plan that would have dramatically
improve their Web site accessibility levels.
Remember Rome was not built in a day and you should take
small steps to begin with so that you can:
·
Properly address training
·
Plan out your accessibility remediation project
·
See and chart the positive results from your efforts
In this chapter
·
An Introduction
to common types of dynamic content
·
Introduction
to database generated content
·
What browser
emulation is and why it needs to be performed as part of your test process
·
Case Study I
– Common Issues with dynamic content
·
Case Study
II – Submitting your site to a popular search engine
The term “dynamic content” is used to describe many
different types of content delivered from different source types. This section
of the book will deal with the testing and evaluation of dynamic Web site
content. The following types of dynamic content will be discussed.
- Content delivered specified on the capabilities of a
particular browser.
- Content delivered based on user’s site login information.
- Content delivered based on a users query to a database.
- Content delivered based on specific server side
programming.
- Content delivered because of server side processing.
Dynamic content introduces special issues. Simply testing
the template may not assure accessibility of the final product. The only way to
be assured that specific accessibility standards are met is to test the sites
“live.”
This means if you have a site that presents different data,
based on the browser that is used to access the site, you should be testing
with every relevant browser. Solutions that provide accessibility testing
should have support for testing sites on the Web and for testing browser
emulation.
There are many different types of dynamic content and
content management and delivery servers on the market today. For the purpose of
this book the most basic will be covered as a means of introducing key concepts
that you will need to understand in order to properly evaluate and repair
accessibility errors.
An underlying component of most dynamic content is the HTML
template. Templates should be tested with verification tools. Templates are
HTML files that have the basic site look and feel. When the user requests
information from the server, the response to the users request and the template
are combined on the server and are presented back to the user. In this case,
to correct accessibility you may just have to correct the template. If the
template is combined with additional HTML to make the final page and there are
errors in the page HTML or the programming that creates the HTML, you will also
need to correct this.
A simple process should be followed when validating and
correcting accessibility of a site that uses templates:
- Validate that the templates are accessible
- If they are not correct them so that they are accessible.
- Validate that any programming that generates the final
page produces accessible HTML.
- If there are programming errors that prevent your site
from being accessible correct them.
- Run an accessibility assessment against your dynamically
generated Web site
- Correct errors as necessary
This process will be the most efficient when testing and
repairing accessibility for a site that uses templates.
A server side include is similar to templates. When you use
server side includes you are simply instructing the Web server to create one
page, which contains the main page and the included content.
For Example: The navigation bar across the top of
the HiSoftware Web site is accomplished with a server side includes.
Server Side Includes should be evaluated in the same way as
you handled templates.
- Validate that the include files are accessible
- If they are not correct them so that they are accessible.
- Run an accessibility assessment against your Web site
- Correct errors as necessary
Note: Testing the server side includes first is the
only way to achieve results that will allow you to plan your site accessibility
project.
Another common type of dynamic content is HTML produced via
a database query selected by a user or program. In this case the HTML is
generally produced as a new page to the user. Another type of dynamic content
produced based on database results would be the implementation of a custom Web
component that allows the user to use their browser as a general table browsing
utility. Both of these types of generic database generated results present
their own distinct challenges.
The most difficult type to remediate or test, from an accessibility
perspective is the Web component. For the purpose of this discussion a Web
component is defined as a Java Applet or ActiveX control. When using Web
components you must make sure that the control that is downloaded to the user
system is accessible under the desktop software accessibility guidelines. If
the Web component is not accessible you must provide alternative access to the
information.
It has become easy for companies to deliver dynamic content
versus static content. Products like Microsoft FrontPage allow users to create
many different types of shared content. Unfortunately companies have not
developed the discipline required to effectively manage their content. It is
recommended that you consider site asset management as part of your
accessibility testing and remediation process.
Recommended Asset categories:
- Images – All Images for a site or folder
- Templates – All Templates used to generate content for
your site
- Scripts – Programmatic components of your site
- Database Access – All database scripts
- Shared – All Shared components or files
- Includes – All HTML Files used as includes
- CSS – Style sheets
Web site developers typically create a method to manage all
Web site content. The challenge is to develop a content creation methodology
that can be used and understood by anyone responsible for maintaining the
site.
Create a file system structure for your Web site if you do
not already have one. For Example: all customer surveys could be stored in the
survey directory. The files system will allow you to easily manage all like
assets.
Develop a naming convention for your html files. The
following list is an example of a naming convention that uses a prefix to the
file that identifies the asset type and allows for simplified accessibility
testing:
inc –include files
tmp – template files
db – a database access file
sh – a shared file
Unless you are a “one-person shop” the developer of the
dynamic site should not be responsible for assuring that its accessibility is
in compliance with global accessibility standards.
There should be a designated person, or team, charged with
testing the dynamic site to assure that it complies with accessibility standards.
Some common myths or inaccurate generalizations about the
testing of dynamic content:
- If I test the site template and it is accessible then the
page generated will be accessible.
- I do not need to test my page because it is data driven.
- If I use HTML 4.0 my site is accessible.
While there can be truth to any one of these statements it
is necessary to test them to prove them right or wrong.
Web based applications are also a form of dynamic content. A
Web based application could be a news portal, driver’s license renewal
application or any other application that runs through the Web browser. Web
based application are generally HTML based or Plug-in based.
For Example: The Web based administration system for
AccessibilityWATCH.COM is 100% HTML. Though it is an application, its content
is HTML and therefore it should comply with Web accessibility guidelines.
Web based applications that are developed as Java Applets or
other Web components will most likely have to comply with the Software
Accessibility Guidelines or paragraph (m) of the Section 508 standards.
When a Web browser or other type of user agent submits a
request for a page from a Web server, part of the request from the browser
includes information about the browser itself, including the name of the agent,
its version, etc (an example of a user agent is Internet Explorer). The Web
server, in most cases, returns a valid Web page to the agent or Web browser.
While the newest Web browsers support this content, Web developers must ensure
the information is accessible to individuals who utilize older browsers.
Below is an example of some pseudo-code a developer might
use in creating a Web page based on this idea.
<%
var browser = Server.CreateObject("MSWC.BrowserType")
ie4 = (browser.version>=4) &&
(browser.browser=="IE")
ns4 = (browser.version>=4) &&
(browser.browser=="Netscape")
if (ie4)
{ %> <P>Do something for Internet Explorer 4
and greater <% }
else if (ns4)
{ %> <P>Do something else for Netscape 4 and
greater <% }
else
{%> <P>Give this content here for everything else
<% }
%>
The above JavaScript code, when used in an Active Server
Page (ASP) on a Web server, delivers content to the Web browser or agent based
on the identity of the user agent. Depending on the design of the Web site and
different options used in writing and delivering the script, the above code
might not be visible to a user viewing the source either through a browser
program such as Internet Explorer or Netscape, or through saving the page
locally to test it. Those users might just see the code for their respective
browser.
In testing a Web site for accessibility, the user wants to
be sure that the Web site is accessible for all users that could view the page.
This functionality is crucial. Often times, the group that reports on Web site
accessibility is not the same group that develops the Web site. In these cases,
the group responsible for the accessibility of the site might not be aware of
the existence of browser-specific functionality and could possibly miss testing
code that was written specifically for a certain brand and version of a Web
browser.
Pages missed in testing can have failing elements that could
go undetected by conventional means.
ABC Company is a major online portal that resells software.
The company resells software products, and is paid a fee for providing secure
transactions and fraud protection for the vendors they represent. The Company
provides product catalog services and ordering from information stored in an
Oracle database.
Software vendors/clients can add information to their Web
presence on the portal, including product logos and descriptive text via a
Web-based Interface or update application. A disabled user (in this case, a
blind user), working with the reseller’s Web based application, would face many
challenges.
In order to bring products to market, the first step of
using the vendor’s application is for the user to log into the product
management system. A quick test of the accessibility of this screen shows major
section 508 and/or W3C errors.
In the example data below, the Priority One
errors that the user will encounter could prevent them from simply logging into
the system and minimally make it very difficult to navigate. This is because of
the following accessibility error:
Checkpoint 12.1 /
(i)
- Failed
Title each frame to facilitate frame identification and navigation.
·
12.1
Rule: All FRAME elements are required to contain the 'title' attribute.
o
Failure - FRAME Element at
Line: 9, Column: 3
o
Failure - FRAME Element at
Line: 11, Column: 5
o
Failure - FRAME Element at
Line: 12, Column: 5
Data 5.1 – Case Study Example
As with the login screen the inner pages have multiple
accessibility problems.
Alternative Text is missing for Images.
- Labels and or Titles are missing from Input Elements.
Note: It is easy to say that
the customer of the commerce site could assign a person without disabilities to
perform the tasks required to create or update the catalog.
However, if the customer was
the government and there was a competitor that provided the same service,
however in an accessible manner, the government would be compelled by law to go
with the competitor.
After the customer of the e-commerce vender enters the
product content via the interface, the data, which is stored in an Oracle
database, is presented when the purchaser (customer) selects the product to
purchase from the e-commerce customers Web site.
The first screen that the customer sees is the product
description page. The page consists of the following important items:
- The companies branding is visible on the page.
- Product image that has a big “Ranked # 1” text on it.
- An image that proudly displays that the store is secure,
virus free and that this is guaranteed.
- There is a compelling input image that instructs the user
to “Buy it now!” (The product that is.)
They also provide text that says to click on “buy it now” to
order.
Now the blind user cannot:
- See company branding.
- See product image or that it is ranked #1.
- See the proud statements of how secure the store is and
how it is virus free.
- Figure out how to buy the product or benefit from the
compelling “Buy it now” image!
Note: You probably just
lost a customer and it would have taken next to nothing to make this page
totally accessible so that any user could have had access to all of the
information.
Now let’s say the customer figured out how to get to the
next page. The next page has the license agreement that must be approved before
going further.
The customer is presented with four images each of which
links to another page or action. They must choose the link that lets them
accept the license agreement.
This page has no alternative text, so again the customer
would be forced with guessing to complete this stage of the order.
The customer would need to click through all of the images
until they found the correct image and were able to continue the order.
The next page has:
- Inaccessible tables to list the products.
- Inaccessible form inputs to select quantity.
- Inaccessible form inputs to choose shipping.
- Inaccessible images to choose platform (operating system)
that the product will run on.
Note: the blind customer would find even more difficulties
in entering address information or credit card information.
It appears that there are three real problems.
- Templates are not accessible.
- Customer Data is not accessible.
- Dynamically generated content is not accessible.
Fixing #1
The Web Development team should assure that all templates are
accessible. The minimal they should strive for is US Section 508 Compliance but
thinking globally means they should develop to the W3C Standards.
Fixing #2
All customer site modifications and data entry applications
should be modified to allow for the entry of accessible information for images
and other accessibility elements that need accessible content.
Note: Most likely this fix
will require modifications to the database storing the information.
Fixing #3
The developers of the store catalog system need to modify
their templates plus, the page generation code to allow for usage of the new
customer data that can now be entered via the enhanced Web based application
that manages customer products.
The e-commerce company should start immediately. There are
many reasons but the most compelling are:
- Perform changes based on their schedule.
- Perform changes before losing customers.
- Likely rise in revenue.
- Great opportunity for press and free marketing.
- Although it is only federal law at this point, most
experts predict that within 2-4 years accessibility will be specified as
part of the ADA.
One of the world’s leading search portals allows users to
submit Web sites to their index. This submission is done by the user through
entering a submission code, Web site URL and a valid e-mail address.
Below are the accessibility issues that would be faced by
disabled users.
File: MajorSearchEngine.htm – failed
Provide a text equivalent for every non-text element (e.g.,
via "alt", "longdesc", or in element content). This
includes: images, graphical representations of text (including
symbols), image map regions, animations (e.g., animated GIFs), applets and
programmatic objects, ascii art, frames, scripts, images used as list bullets,
spacers, graphical buttons, sounds (played with or without user interaction),
stand-alone audio files, audio tracks of video, and video.
- 1.1
Rule: All IMG elements are required to contain either the 'alt' or the
'longdesc' attribute.
- Failure - IMG Element
at Line: 104, Column: 1
- Failure - IMG Element
at Line: 157, Column: 44
- Failure - IMG Element
at Line: 234, Column: 18
- 1.1
Rule: All INPUT elements are required to contain the 'title' attribute or
use a LABEL.
- Note:
INPUT Element found at Line: 82, Column: 1 does not contain the 'title'
attribute, however, it is of type 'hidden' and does not represent an
accessibility problem.
- Note:
INPUT Element found at Line: 83, Column: 1 does not contain the 'title'
attribute, however, it is of type 'hidden' and does not represent an
accessibility problem.
- Failure - INPUT
Element at Line: 111, Column: 48
- Failure - INPUT
Element at Line: 125, Column: 29
- Failure - INPUT
Element at Line: 133, Column: 29
- Failure - INPUT
Element of Type IMAGE at Line: 134, Column: 1
The Impact of this accessibility issues it that a person
with no vision could not add their URL to the index
Other accessibility problems for submission include:
- Alternative Text is not available for the submission code
(which is an image); this is required for submission to the index.
- A title is not used nor is a label for the text box used
to enter the submission code.
- A title is not used nor is a label for the text box used
to enter the URL
- A title is not used nor is a label for the text box used
to enter the users e-mail text.
- A title is not used nor is a label for the input element,
of type image, is used to submit the information.
This seems relatively simple, however, it becomes more
complex if the user cannot read the image and enter it in as the submission
code. If this is the case, the user CANNOT add a page via the form, even if
they were able to get by the other errors on this site.
The application also provides no instruction for submitting
to the index if you cannot read the image, which is the code required for
submission.
The Engine uses this practice to “Combat Spam” to their
engine. This prevents automatic submission tools from submitting to their
index. It is recommended that the search engine company perform the following
steps to repair the accessibility errors:
- Correct all page accessibility errors.
- Provide a submission code that can be read by all users
- Provide a link on the page for users with weak or no
vision where they can submit pages to the index or apply for a code that
can be used to complete normal submission.
8. The Unseen
meaning
In this chapter
·
An
introduction to metadata for improved content accessibility
·
A Guide to
writing text equivalents
·
Writing text
equivalents for images.
·
Common
practices and errors when writing alternative text
This section discusses non-visual components, which can
significantly impact the accessibility of a page.
Metadata is an excellent way to communicate information
about a document or resource that directly relates to accessibility.
Metadata is information about a document. The information
you use to describe a document can help users identify whether the document is
helpful to them and how to locate the document readily.
The precursor to metadata is the card catalog. For each item
in a library collection, there are three entries in the card catalog: title,
author, and subject. A card indicates the location of an item in the
collection, and provides additional information about it, such as the
publisher, format, genre, date of publication, and volume size. While the card
catalog serves as a database for the library, metadata goes a step further -
metadata becomes part of the electronic file and remains in the source code no
matter where the file moves. When you use metadata correctly, you can provide
helpful information about a file to the user. The use of metadata has been
recommended by W3C®, or World Wide Web Consortium, as a Priority 2
Checkpoint for Web accessibility.
Checkpoint 13.2 of the W3C accessibility guidelines states
that you should provide metadata to add semantic information to pages and
sites.
You should include author name, company
rights, type of content, etc…
Metadata is stored in the form of Meta tags. There are some
common Meta tags that are recognized readily by indexing services on the
Internet. In addition, you can create custom Meta tags that are helpful to
members of your organization.
The most important part of using metadata is that you apply
it uniformly to your document collection and that you use it accurately. When
you use metadata inappropriately, in an attempt to gain higher visibility on
the Internet, you can jeopardize your ranking with search engines. Additionally
from an accessibility standpoint you are basically providing misleading or
inaccurate information regarding a resource.
The Meta tag is placed in the HEAD section of an HTML
document.
Example:
<HEAD>
<Meta
name=”Author” content=”Yonaitis”>
</HEAD>
You can place as many metadata elements in the document as
are required to adequately describe the resource.
Although many organizations have recommended the use of
metadata to boost usability and enhance accessibility, it is difficult to find
specific information about the Meta tags that should be used. Below are some of
the most commonly utilized Meta tags.
Keywords
Each document should have keywords.
The words you use to describe your document should occur in the document body
text.
Description
Each document should have a
description. The words you use to describe your document should occur in the
document body text.
Author
Each document should have at least
one author. The author can be an organization, one or more individuals, or
both.
Language
The language Meta tags indicates
the primary language of a document. There is a list of common language codes.
For example, the language code for United States English is en-us.
Robots
The robots Meta tag value provides
instructions to crawlers on how to crawl, or index, the document and other
documents linked to it.
Rating
The rating tag reveals information about the
content of your document to users. This helps users to screen information that
might not be appropriate for all viewers.
Copyright
The copyright Meta tag includes the
name of the copyright holder and a statement of permissible use.
You can add metadata directly to the head section of
documents using a Web editor, like Microsoft®
FrontPage®. This manual method works for document authors who need
to add metadata to describe the contents of a particular document.
Some metadata values should be consistent across your
document collection. This helps avoid inconsistencies and data entry mistakes
by document authors. There are software tools to help you add metadata
systematically to individual documents, groups of documents, or an entire
document collection.
Accessibility with regard to Web content can have two
meanings:
- A user can gain access to the content; this is the more
traditional meaning.
- A user can understand (gather the meaning of) the content.
This is the challenge!
Text equivalents are necessary for all non-text elements.
When you write text equivalents, you are providing
information about non-text Web elements to people with disabilities that would
otherwise be prevented from having access to the information.
To minimize confusion for the user, consider the following
recommendations:
- If you are linking to a document: Note what kind of
document you are linking to, remember if the document requires a plug-in
to view you MUST provide information on where the user can get the plug-in
and the version required.
- Fully describe the meaning and purpose of any image.
- When you refer to numbers, be clear about the units of
measure.
- When you describe tables or graphs, describe the general
characteristics of both the x and y-axis if applicable.
There has been much discussion on the use of the word “Logo”
in alternative text. This brings up a very interesting intersection between
branding and what is best for the site visitor that cannot see images because
of a technology limitation or physical disability.
A company will want it to be clear that every page is part
of their Web property. In this case the logo and meaning are very important. It
is recommended that the Web site also provide a long description that fully
describes the logo and what the site visitor should be taking away with them as
the meaning of the logo.
One of the major problems that users of screen readers
encounter is the use of repetitive or meaningless link text, which is used to
direct users to additional site content.
This is a problem because the screen reader will gather all
of the links on a page. Then the links will be presented in a manner that is
easy for the user to select the links to go to the additional resources. When
the screen reader does this it does not bring in all of the associate text
around the link.
Because of this common conventions that designers use for
visual navigation can cause problems to those with blind users or those with
limited vision.
Example of the problem
The list below is of some content that appears on a web site
and how the use of “Click Here” can make it difficult for a user of assistive
technology to navigate the site.
The Italic Text Represents the Hyperlink Text
Product “a” is a Fruit Substitute
recommended by many leading physicians
For more information on product “a”
click here
Product “b” is a Meat Substitute recommended by
many leading physicians
For more information on product “b”
click here
Product “c” is a Grain Substitute
recommended by many leading physicians
For more information on product “c”
click here
In the above example the screen reader would bring up the
link text “Click Here” for all of the products, a-c. This would not have
meaning to someone who could not see the placement of the link.
The proper way build the links would have the link text be
more descriptive.
The Italic Text Represents the Hyperlink Text
Product “a” is a Fruit Substitute
recommended by many leading physicians
For more information on product
“a” click here
Product “b” is a Meat Substitute recommended by
many leading physicians
For more information on product
“b” click here
Product “c” is a Grain Substitute
recommended by many leading physicians
For more information on product
“c” click here
In the above link text the full line that has click here in
it is now the link, allowing for easy identification of what the link actually
provides and where it goes.
Images are used for their meaning and in most cases add
meaning because of their location or function on the page. With this in mind
you need to provide full and qualified alternative text representation for the
image so that people with disabilities, who cannot view the image, for any
reason, understand the full meaning of the image. In developing exclusively to
the standards, you may miss the meaning and the importance of the rules. If you
do this you can get by using verification tools but your site may NOT be
accessible.
The following practices should not be followed, as they do
the exact opposite of the desired result for using alt text with images.
Marketing Play
Many developers will use the alt text properties of
images to enter marketing keywords about their Web site rather than to describe
the image or its purpose. This is accomplished by entering keywords versus
descriptive text. Example: there is an image of a company logo, the alt text
should read alt=”My Company Logo” instead the alternative text says
alt=”Keyword 1, Keyword 2, Keyword 3, Keyword Phrase, Keyword Phrase 2, Keyword
Phrase 3…”
This practice should cease
and corrections should be made to any text that has been entered incorrectly.
Image Name as Alternative Text
In the past there were many
editors, or dynamic generation systems, which input the image name as
alternative text.
Example:
<img border="0"
src="images/logo32-gif.gif" alt="logo32-gif.gif ">
This clearly has no meaning to the
average person viewing the page. All editors need to be informed on correctly
adding accessible alt text. Any incorrect alternative text should also be
updated.
Incomplete Text
This is also a common problem. In
order to satisfy accessibility requirements some organizations are rushing to
add alternative text without taking the time to make it meaningful.
Example:
There is an image that is a link to a priority
service; the image is 100% text and a gradient background.
The image text reads:
Be more competitive with
Priority service – Go there now.
The alternative text reads:
Alt=”Priority Service”
Although alternative text is
provided in this scenario, it is incorrect, as it does not clearly represent
the significance of the image. It would take minimal effort to modify the
alternative text to accurately represent the image, and its intended meaning.
Once modified, the alternative text
reads:
Alt=” Be more competitive with
Priority Service – go there now!”
It is easy to see how this difference in content
has conveyed new meaning to the image. The effort associated in altering the
text, and making the image “accessible” was minimal. One point to note is that
when the accessibility tasks are done correctly originally there is no related
cost to creating and maintaining an accessible site.
Make it Readable
Many WYSIWYG or HTML Editors
provide no default facility for spell checking element properties like ALT.
With this in mind, remember to verify the spelling of your alternative text.
Note: It is difficult to read “car” from “cra”. Make sure that your text is
readable and has correct spelling.
The use of Alternative text for images can be confusing;
especially around an image that is simply formatted text. It is common for
designers to do this to protect and or control the look of text.
The Problem occurs when the site developer or accessibility
expert puts the design meaning versus the screen meaning for the alt text. In
the example below you have the HiSoftware Publishing Tag line as an image.
Design: HiSoftware
Publishing Tag Line
Alt Text: HiSoftware
Publishing - Peel open the cover of one of these useful books
So if we misinterpret the
alternative text requirement and put the designers meaning versus what the
intent of the image to the site visitor is we will not satisfy the requirement.
Follow a Simple rule: If there is
text in the image then the same text should be in the alternative text
attribute
Although, it is easy to list the bad practices, it is more
important to focus on the simple steps associated with providing accessible
alternative text for images. The book will now introduce some good practices
and suggestions on providing meaningful alternative text for images. Below is a
list of recommended practices:
- Spell check your alternative text.
- Use punctuation, if applicable.
- Match text to the meaning of image.
- Always read back the alternative text to ensure it will
convey the intended meaning.
Some of the most common questions, in regards to providing
accessible alternative text, are listed below:
When should I address alternative text?
The application of alternative text for images
should be performed as soon as they are placed on a page. This will ensure
accuracy and efficiency.
In my organization we submit content to a graphics
designer and they provide an image, I cannot always adequately articulate what
the designer meant in alt text what do you recommend?
This is a good question; it addresses a very
important issue for organizations that use a different design and content group
to create the final page.
The obvious answer is to ask the designer why this
image and why use it.
But more importantly perhaps the company’s delivery
policy of graphics needs to be changed to have the designer send not only the
image but also the base alternative text.
Secondly, the page designer may add more meaning
through the placement of the image as well as the function it performs as
either a link or image map.
My image is transparent and cannot be seen, it is used
merely for spacing of content as a design tool. Do I need alternative text?
The best practice is to use alternative text with a
value of a space because it effectively translates its use.
Example:
<img
src="images/spacer.gif" alt=" ">
My image cannot be described briefly. Should I use
alternative text greater than 80 characters to describe my image?
When an image cannot be described briefly, use the
longdesc attribute. The longdesc attribute allows you to indicate the URL that
contains a long description of the image.
This might be useful for images that convey
detailed information to the user, such as schematic diagrams and maps.
In this chapter
·
Learn how to
make IMAGES and FORMS accessible
·
Learn how to
make APPLETS and OBJECTS accessible
·
Learn to
create a D-Link and an IMAGE with the “longdesc” Attribute
·
Learn how to
create accessible inline frames
·
Learn the
proper way to create a bulleted list that uses images for bullets
·
Learn how to
create redundant text links for Server-Side image maps
·
Learn how to
work with color
·
Learn how to
produce accessible image maps
·
Learn why
you need to avoid BLINK and MARQUEE
·
Learn how to
make a TABLE accessible
·
Learn how to
correct common SCRIPT accessibility errors
·
Learn how to
follow Section 508 paragraph (o)
·
Full
examples for every accessibility task
This section of the book provides guidelines and examples
designed to teach the reader how to develop accessible content. The section is
organized with the following conventions:
Section + Rule (Section 508 / W3C)
Current HTML –
original HTML example
Corrected HTML –
accessible HTML
Note: If you have more questions on the rules
themselves or on what disabilities are addressed by a specific rule, please see
Chapter Two.
For this tutorial we will look at different pages on the
Internet, these pages are designed to cover specific accessibility defects.
Those developing a site to meet Section 508 standards or W3C guidelines will
find this section valuable.
The tutorial can be used as a workshop to introduce you to
Section 508 or W3C/WCAG accessibility guidelines. It can also be used as a
general reference on how to correct specific accessibility issues.
If you are new to creating accessible content it is
recommend that you use it as a workshop. Once you have completed the examples
you should be ready to apply what you have learned to your Web site.
Remember to follow along in your Web page editor you must
first download the example.
Please visit http://www.understandingaccessibility.com/ for
the example files
To do this: Open the above page in Internet Explorer and
save it locally by completing the following steps.
1
Open the above page in your browser
2
Select File |Save As
3
Type in fpdemo1.htm in the filename input box, make sure you selected to
save as complete web page so you will have all demo files.
4
Click on the Save button
If you purchased the eBook these files were included in a
zip file called demos.zip. Extract this file to your hard drive.
Now open the saved file in your Web page editor. The
accessibility issues that will be covered by section one are:
A text equivalent for every
non-text element shall be provided (e.g., via "alt",
"longdesc", or in element content).
·
All IMG elements are required to contain either the 'alt' or the
'longdesc' attribute.
·
All INPUT elements are required to contain the title attribute or
use a LABEL.
·
All OBJECT elements are required to contain element content.
·
All APPLET elements are required to contain both element content
and the alt attribute.
·
All IFRAME elements are required to contain element content.
·
All Anchor elements found within MAP elements are required to
contain the 'alt' attribute.
·
All AREA elements are required to contain the 'alt' attribute.
The first Image represents “conserve”. The images purpose is
simply to add the meaning of conserve. The rule states all IMG elements are
required to contain either the 'alt' or the 'longdesc' attribute.
This image requires alternative
text.
Current HTML – EXAMPLE 1
In the current HTML the alt
attribute is missing.
<IMG
border="0" src="../images/j0293240.gif"
width="165" height="122">
Corrected HTML – EXAMPLE 1
In the corrected HTML the alt
attribute is used.
<IMG
border="0" src="../images/j0293240.gif"
width="165" height="122" alt=”Conserve Icon”>
This example demonstrates an image with a navigation
purpose. The purpose is to provide a navigation link to the HiSoftware home
page. The rule states all IMG elements are required to contain either the 'alt'
or the 'longdesc' attribute.
Current HTML – EXAMPLE 2
In the current HTML the alt
attribute is missing.
<IMG
border="0" src="../images/j0293240.gif"
width="165" height="122">
Corrected HTML – EXAMPLE 2
In the corrected HTML the alt
attribute is used and the alt text also shows the purpose of the image.
<a href="http://www.undersyandingaccessibility.com/">
<IMG
border="0" src="../images/j0293240.gif"
alt="Conservation
Symbol and link to HiSoftware Home Page" width="165"
height="122"></a>
Note:
To create effective alternative text for your non-text elements makes sure you:
·
Follow the guide in this book for developing alternative text
·
Use a spell checker
This example demonstrates the use of “longdesc.” It would be
difficult to describe this image with alternative text only. In this case a
long description should be used. The rule states that all IMG elements are
required to contain either the 'alt' or the 'longdesc' attribute.
Current HTML – EXAMPLE 3
In the current HTML the alt
attribute is missing and there is no longdesc attribute.
<Img
border="0" src="../../images/j0301076.gif"
width="192" height="192"></font></p>
Corrected HTML – EXAMPLE 3
In the corrected HTML the alt
attribute and longdesc attribute are used. In addition to this a d-Link was
used.
<Img border="0"
src="../../images/j0301076.gif" alt="Space Related Objects - See
Long Description" width="192" height="192" longdesc="AboutSpace.html">
<A
href="AboutSpace.html">[D]</A>
Example four demonstrates the proper accessibility coding
for an ActiveX object. The object is of a Microsoft Office Web component. The
rule states All OBJECT elements are required to contain element content.
Current HTML – EXAMPLE 4
The element content is missing from
the current HTML.
<object
classid="clsid:0002E551-0000-0000-C000-000000000046"
id="Spreadsheet1" width="319" height="249">
<param
name="DataType" value="XMLDATA">
</object>
Corrected HTML – EXAMPLE 4
In the corrected HTML the element content is present.
<object
classid="clsid:0002E551-0000-0000-C000-000000000046"
id="Spreadsheet1" width="319" height="249">
<param
name="DataType" value="XMLDATA">
Your
browser does not support this object.
This
is an object and it represents data that is also available at [object
location]
</object>
Example five demonstrates the proper accessibility coding
for a Java applet. The rule states that all APPLET elements are required to
contain both element content and the alt attribute.
Current HTML – EXAMPLE 5
In the current HTML the element
content and alt attribute are missing.
<applet
width="128" height="128"
code=""
codebase="http://Example.js.class/">
</applet>
Corrected HTML – EXAMPLE 5
In the corrected HTML the element
content and the alt attribute are present.
<applet
width="128" height="128"
code=""
alt=”My Applet Description”
codebase="http://Example.js.class/">
This
is a navigation applet. Alternative navigation can be found at: [navigate
location]
</applet>
Example six demonstrates the proper accessibility coding for
a standard HTML form. The rule states that all INPUT elements are required to
contain the 'title' attribute or use a LABEL.
Current HTML – EXAMPLE 6
In the current HTML the
alternative text for the input element is not present.
<Input type="text" name="T1"
size="20">
</form>
Corrected HTML – EXAMPLE 6
In the corrected HTML the
alternative text for the input element is present.
<Form method="POST"
action="-WEBBOT-">
<Input type="text"
name="T1" size="20" title=”First Name”> </form>
Adding LABELS: In the
corrected HTML the alternative text for the input element is present and LABELS
have been added.
<Form method="POST"
action="-WEBBOT-">
<Label for="T1"> User Name: </label>
<Input type="text"
id=”T1” name="T1" size="20" title=”First Name”> </form>
Note: Using both Label and title gives you increased
usability of your form. (Only use both if the text is different, label is
preferred)
Example seven demonstrates the proper accessibility coding
for Inline frames. Inline frames prove an excellent TABLE or FRAME alternative.
The rule states that all IFRAME elements are required to contain element
content.
Current HTML – EXAMPLE 7
In the current HTML the element
content for the IFRAME element is not present.
<Iframe name="I1"
SRC="sample.htm">
</iframe>
Corrected HTML–
EXAMPLE 7
In the corrected HTML the element
content is present.
<Iframe name="I1"
SRC="sample.htm">
Your browser does not support
inline frames or is currently configured not to display inline frames. Content
can be viewed at actual source page:
http://understandingaccessibility.com/
</iframe>
8. Image Map Example
(Section 508 (f))
Example eight demonstrates the proper accessibility coding
for an Image Map. The rule states that all AREA elements are required to
contain the 'alt' attribute.
Current HTML – EXAMPLE 8
In the current HTML the
alternative text for the area elements and alternative text for the image are
not present.
<map
name="FPMap0">
<area
href="#Go Here for Links!!!" shape="rect" coords="13,
5, 172, 75">
<area
href="#Go Here for Links!!!" shape="rect" coords="8,
92, 119, 187">
<area
href="#Go Here for Links!!!" shape="rect" coords="125,
91, 191, 180">
</map>
<img
border="0" src="../../images/j0301076.gif"
usemap="#FPMap0" width="192" height="192">
Corrected HTML – EXAMPLE 8
In the corrected HTML the
alternative text for the area elements and alternative text for the image are
present.
<map
name="FPMap0">
<area
href="#Go Here for Links!!!" shape="rect" coords="13,
5, 172, 75" alt=”My Alternative Text”>
<area
href="#Go Here for Links!!!" shape="rect" coords="8,
92, 119, 187" alt=”My Alternative Text”
<area
href="#Go Here for Links!!!" shape="rect" coords="125,
91, 191, 180" alt=”My Alternative Text”>
</map>
<img
border="0" src="../../images/j0301076.gif"
usemap="#FPMap0" width="192" height="192"
alt=”Space Image”>
Example nine demonstrates the proper accessibility coding
for a bullet list, where the bullets are actually images. The rule states All
IMG elements are required to contain either the 'alt' or the 'longdesc'
attribute.
Current HTML – EXAMPLE 9
In the current HTML there are
five products listed, these products have an image before the product name to
create a fashionable bulleted list.
<p>HiSoftware
Accessibility Products by Robert Yonaitis</p>
<p><img
border="0" src="BD10263_.GIF">
Understanding
Accessibility Book</p>
<p><img
border="0" src="BD10263_.GIF">
AccVerify</p>
<p><img
border="0" src="BD10263_.GIF">
AccRepair</p>
<p><img
border="0" src="BD10263_.GIF">
AccMonitor</p>
<p><img
border="0" src="BD10263_.GIF">
AccessibilityWATCH</p>
Corrected HTML – EXAMPLE 9
The guidelines state that the purpose of the image is very
important, the purpose in this case has nothing to do with the visual
representation, and it is merely a bullet. This is definitely an exception to
previously stated rules. The exception is: describing the image in the
alternative text would not be effective instead we will describe the purpose.
HiSoftware
Accessibility Products
<p><img
border="0" src="BD10263_.GIF" alt=”*”>
Understanding
Accessibility Book</p>
<p><img
border="0" src="BD10263_.GIF" alt=”*”>
AccVerify</p>
<p><img
border="0" src="BD10263_.GIF" alt=”*”>
AccRepair</p>
<p><img
border="0" src="BD10263_.GIF" alt=”*”>
AccMonitor</p>
<p><img
border="0" src="BD10263_.GIF" alt=”*”>
AccessibilityWATCH</p>
In this case the asterisks clearly describe the value and
purpose of the images as bullets.
This section does not contain demonstration files but simply
lists tips for Section 508 (b) Equivalent alternatives for any multimedia
presentation shall be synchronized with the presentation.
There are different types of audio files-all require text
equivalents. Consider the following audio files:
- Stand-alone audio files, such as music that plays during a
multimedia presentation or at the request of the user
- Interactive audio files, such as an alert tone, that only
plays when the user has performed a specific task
Creating Accessible Audio Files
You have several options if you need to provide equivalent
text for sound and audio files.
Static Text Equivalent
You can display static, or non-moving, text during the
sound. This technique is most effective for sounds that require user input,
such as stand-alone audio or interactive audio.
Stand-alone audio is a file that the user plays by
some action or command. For example, Clicking on an element plays an audio
file.
Interactive audio is sound that occurs because the
user has performed an action or command. For example, any error or interactive
action that results in an audio warning or prompt based on user action must
also have a visual equivalent.
Link to Text Transcript
You can provide a link to a text transcript of an audio
file. This technique is most effective for stand-alone audio files, such as
music.
When you provide a link to the text transcript, position the
link near the top of the page, frame, or table cell. When you create a text
transcript, use a description that accounts for both spoken and non-spoken
sound, and be sure to differentiate between them.
For example, suppose you are viewing a page about United
States history. Near the top of the page there are two links:
- Listen to the earliest recording of the national anthem.
- See a text transcript of the earliest recording of the national
anthem.
However, if the page automatically plays the national
anthem, there should be some indication to the user that sound is being used.
The best technique for sounds that plays automatically is static text done by
scripting.
The demo file for this section can be downloaded from the
internet
http://understandingaccessibility.com/
Remember to follow along in your Web page editor you must
first download the example. To do this: Open the above page in Internet
Explorer and save it locally by completing the following steps.
1. Open
the above page in your browser
2. Select
File |Save As
3. Type
in fpdemo3.htm in the filename input box, make sure you selected to save as
complete web page so you will have all demo files.
4. Click
on the Save button
If you purchased the eBook these files were included in
a zip file called demos.zip. Extract this file to your hard drive.
Now open the saved file in your Web page editor and we are
ready to begin. The accessibility issue that will be covered by section three
is:
Web pages shall be designed so that all information
conveyed with color is also available without color, for example from context
or markup.
Example one demonstrates an incorrect use of color. Color is
used to communicate user navigation. This example has the user perform an
action based on the color of text. This could be a desirable design practice,
however it could be meaningless to someone who had vision disabilities that
prevented him or her from identifying the color.
Current HTML – EXAMPLE 1
In the current HTML the color is the only way to determine
how to go to the correct product.
Thank you
for your interest in our product. For
those
with:</font>
<p><font
size="2" face="Verdana">Product A Follow Instructions
that are in Red</font></p>
<p><font
size="2" face="Verdana">Product B Follow Instructions
that are in Green</font></p>
<p><font
color="#FF0000" size="2" face="Verdana">Register
your Product Here</font></p>
<p><font
color="#008000" size="2"
face="Verdana">Register your Product Here</font></p>
Information
This HTML could be corrected by simply providing more
descriptive text. Developing accessible pages does not prevent you from using
color. You must simply take into account that a Web site visitor may be blind
or colorblind. If this is the case then visual prompts will not allow the user
to complete the process that you have designed.
Corrected HTML – EXAMPLE 1
In the corrected HTML color is no longer the only way to
determine the correct action.
Thank you
for your interest in our product. For
those
with:</font>
<p><font
size="2" face="Verdana">Product A Follow Instructions
marked A that are in Red</font></p>
<p><font
size="2" face="Verdana">Product B Follow Instructions
Marked B that are in Green</font></p>
<p><font
color="#FF0000" size="2"
face="Verdana">Register your Product AHere</font></p>
<p><font
color="#008000" size="2"
face="Verdana">Register your Product B Here</font></p>
Example two demonstrates a bad use of color. This example
uses colored text to communicate which fields of a form are required for
successful submission.
Current HTML – EXAMPLE 2
In the current HTML color is the only way to determine which
fields are required to submit the form.
<form
method="POST" action="--WEBBOT--">
<p>Required fields are RED</p>
<p>User Name <input type="text" name="T1"
size="20"></p>
<p>User Address <input type="text" name="T2"
size="20"></p>
<p><font color="#FF0000">User E-Mail
Address</font><input type="text" name="T3"
size="20"></p>
<p><input type="submit" value="Submit"
name="B1"></p>
</form>
Corrected HTML – EXAMPLE 2
In the corrected HTML color is not the only way to determine
which fields are required to submit the form.
<form
method="POST" action="--WEBBOT--">
<p>Required
fields are RED and Marked with an *</p>
<p>User
Name
<input
type="text" name="T1" size="20"></p>
<p>User
Address
<input
type="text" name="T2" size="20"></p>
<p><font
color="#FF0000">* User E-Mail Address</font>
<input
type="text" name="T3" size="20"></p>
<p>
<input
type="submit" value="Submit" name="B1">
</p>
</form>
Apply what you have learned
In the above example the completion of the form can be
accomplished without any dependence on color. However the form itself is not
accessible. Use titles and labels to make the form accessible!
The demo file for this section can be downloaded from the
internet
http://www.understandingaccessibility.com/
Remember to follow along in your Web page editor you must
first download the example. To do this: Open the above page in Internet
Explorer and save it locally by completing the following steps.
1. Open
the above page in your browser
2. Select
File |Save As
3. Type
in fpdemo4.htm in the filename input box, make sure you selected to save as
complete web page so you will have all demo files.
4. Click
on the Save button
If you purchased the eBook these files were included in
a zip file called demos.zip. Extract this file to your hard drive.
Now open the saved file in your Web page editor and we are
ready to begin. The accessibility issue that will be covered by section four
is:
Redundant text links shall be provided for each
active region of a server-side image map.
Example one demonstrates how to use redundant text links to
make a server side image map accessible.
Current HTML
<A
href="http://www.undersyandingaccessibility.com/scripts/imagemap/accessmap">
<IMG
src="../../images/ACCVerifybut88.gif"
ismap width="88" height="31"></A>
Information
Remember when correcting this image map you need to use
alternative text for the image.
Corrected HTML
<A
href="http://www.undersyandingaccessibility.com/scripts/imagemap/accessmap">
<IMG
src="../../images/ACCVerifybut88.gif"
alt="Get
AccVerify Approved(Text links follow)"
ismap width="88" height="31"></A></font>
<p>
[<A href="../access/vindex.html">
AccVerify
Home</A>] </font></p>
<p>
[<A href="../access/approved.html">
The
Approved Logo Meaning</A>]</p>
The demo file for this section can be downloaded from the
internet
http://understandingaccessibility.com/
Remember to follow along in your Web page editor you must
first download the example. To do this: Open the above page in Internet
Explorer and save it locally by completing the following steps.
1. Open
the above page in your browser
2. Select
File |Save As
3. Type
in fpdemo4.htm in the filename input box, make sure you selected to save as
complete web page so you will have all demo files.
4. Click on the Save
button
If you purchased the eBook these files were included in
a zip file called demos.zip. Extract this file to your hard drive.
Now open the saved file in your Web page editor and we are
ready to begin. The accessibility issues that will be covered by section five
are:
(g) / 5.1
·
All Cells in the first row must be column header cells
·
All Cells in the first column must be row header cells
·
Tables used for data should have a caption
- All column header cells are required to contain the scope
attribute
- All row header cells are required to contain the scope
attribute
- All column header cells are required to contain the id
attribute
- All row header cells are required to contain the id
attribute
- All data cells are required to contain the headers
attribute
- All data cells are required to contain the axis attribute
- When row grouping elements are used, all rows are required
to be grouped
Example one demonstrates how to add headers to rows and
columns.
Current HTML – EXAMPLE 1
The current HTML example has not identified row and column
headers.
<table border="1"
cellpadding="4" cellspacing="0" width="100%">
<tr>
<td
width="25%">Time of day</td>
<td
width="25%">Food</td>
<td
width="25%">Drink</td>
<td
width="25%">Time allotted for meal</td>
</tr>
<tr>
<td
width="25%">6 am</td>
<td
width="25%">Eggs</td>
<td
width="25%">Juice</td>
<td
width="25%">30 minutes</td>
</tr>
<tr>
<td
width="25%">11am</td>
<td
width="25%">Sandwich</td>
<td
width="25%">Water</td>
<td
width="25%">30 minutes</td>
</tr>
</TABLE>
Corrected HTML – EXAMPLE 1
To correct the HTML we add Row and Column headers
<TABLE cellSpacing=0
cellPadding=4 width="100%" border=1>
<TR>
<TH
width="25%">Time of day</TH>
<TH
width="25%">Food</TH>
<TH
width="25%">Drink</TH>
<TH
width="25%">Time allotted for meal</TH></TR>
<TR>
<TD
width="25%">6 am</TD>
<TD
width="25%">Eggs</TD>
<TD
width="25%">Juice</TD>
<TD
width="25%">30 minutes</TD></TR>
<TR>
<TD
width="25%">11am</TD>
<TD
width="25%">Sandwich</TD>
<TD
width="25%">Water</TD>
<TD width="25%">30
minutes</TD></TR></TABLE>
Example two demonstrates how to add a CAPTION to a data
table.
Current HTML – EXAMPLE 2
The current HTML is missing the CAPTION element. Remember a
CAPTION will be visible on the screen.
<TABLE
cellSpacing=0 cellPadding=4 width=”100%” border=1>
<TR>
<TH width=”25%”>Time of day</TH>
<TH width=”25%”>Food</TH>
<TH width=”25%”>Drink</TH>
<TH width=”25%”>Time allotted for meal</TH></TR>
<TR>
<TD width=”25%”>6 am</TD>
<TD width=”25%”>Eggs</TD>
<TD width=”25%”>Juice</TD>
<TD width=”25%”>30 minutes</TD></TR>
<TR>
<TD
width=”25%”>11am</TD>
<TD width=”25%”>Sandwich</TD>
<TD width=”25%”>Water</TD>
<TD width=”25%”>30 minutes</TD></TR>
<TR>
<TD width=”25%”>3pm</TD>
<TD width=”25%”>Steak</TD>
<TD width=”25%”>Water</TD>
<TD width=”25%”>1 Hour</TD></TR></TABLE>
Corrected HTML – EXAMPLE 2
The corrected HTML now has the
CAPTION added right below the TABLE element.
<TABLE
cellSpacing=0 cellPadding=4 width="100%" border=1>
<CAPTION>Table about Meals and times allotted for eating</CAPTION>
<TR>
<TH width="25%">Time of day</TH>
<TH width="25%">Food</TH>
<TH width="25%">Drink</TH>
<TH width="25%">Time allotted for meal</TH></TR>
<TR>
<td width="25%">6 am</td>
<TD width="25%">Eggs</TD>
<TD width="25%">Juice</TD>
<TD width="25%">30 minutes</TD></TR>
<TR>
<td width="25%">11am</td>
<TD width="25%">Sandwich</TD>
<TD width="25%">Water</TD>
<TD width="25%">30 minutes</TD></TR>
<TR>
<td width="25%">3pm</td>
<TD width="25%">Steak</TD>
<TD
width="25%">Water</TD>
<TD width="25%">1 Hour</TD></TR></TABLE>
Example three demonstrates how to add the scope attribute.
Current HTML – EXAMPLE 3
The current HTML example does not contain the scope
attribute.
<TABLE
cellSpacing=0 cellPadding=4 width="100%" border=1>
<TR>
<TD width="25%">Time of day</TD>
<TD width="25%">Food</TD>
<TD width="25%">Drink</TD>
<TD width="25%">Time allotted for meal</TD></TR>
<TR>
<TD width="25%">6 am</TD>
<TD width="25%">Eggs</TD>
<TD width="25%">Juice</TD>
<TD width="25%">30 minutes</TD></TR>
<TR>
<TD width="25%">11am</TD>
<TD width="25%">Sandwich</TD>
<TD width="25%">Water</TD>
<TD
width="25%">30 minutes</TD></TR></TABLE>
Corrected HTML – EXAMPLE 3
The HTML is modified and now contains the scope attribute.
<TABLE
cellSpacing=0 cellPadding=4 width="100%" border=1>
<TR>
<TH scope="col" width="25%">Time of day</TH>
<TH
scope="col" width="25%">Food</TH>
<TH scope="col" width="25%">Drink</TH>
<TH scope="col" width="25%">Time allotted for
meal</TH></TR>
<TR>
<TD width="25%">6 am</TD>
<TD width="25%">Eggs</TD>
<TD width="25%">Juice</TD>
<TD width="25%">30 minutes</TD></TR>
<TR>
<TD width="25%">11am</TD>
<TD width="25%">Sandwich</TD>
<TD width="25%">Water</TD>
<TD width="25%">30 minutes</TD></TR></TABLE>
Example four demonstrates the correct use of the header
attribute.
Current HTML – EXAMPLE 4
The current HTML example does not contain header attributes.
<TABLE
cellSpacing=0 cellPadding=4 width="100%" border=1>
<TR>
<TD width="25%">Time of day</TD>
<TD width="25%">Food</TD>
<TD width="25%">Drink</TD>
<TD width="25%">Time allotted for meal</TD></TR>
<TR>
<TD width="25%">6 am</TD>
<TD width="25%">Eggs</TD>
<TD width="25%">Juice</TD>
<TD width="25%">30 minutes</TD></TR>
<TR>
<TD width="25%">11am</TD>
<TD width="25%">Sandwich</TD>
<TD width="25%">Water</TD>
<TD width="25%">30 minutes</TD></TR></TABLE>
Corrected HTML – EXAMPLE 4
The corrected HTML has the required header attributes.
<TABLE
cellSpacing=0 cellPadding=4 width="100%" border=1>
<TR>
<TH id="header5" width="25%">Time of day</TH>
<TH id="header6" width="25%">Food</TH>
<TH id="header7" width="25%">Drink</TH>
<TH id="header8" width="25%">Time allotted for
meal</TH></TR>
<TR>
<TD headers="header5" width="25%">6 am</TD>
<TD headers="header6" width="25%">Eggs</TD>
<TD headers="header7" width="25%">Juice</TD>
<TD headers="header8" width="25%">30
minutes</TD></TR>
<TR>
<TD headers="header5" width="25%">11am</TD>
<TD headers="header6"
width="25%">Sandwich</TD>
<TD headers="header7" width="25%">Water</TD>
<TD
headers="header8" width="25%">30
minutes</TD></TR></TABLE>
Example five demonstrates the correct use of the axis
attribute.
Current HTML – EXAMPLE 5
The current HTML example does not contain axis attributes.
<TABLE
cellSpacing=0 cellPadding=4 width="100%" border=1>
<TR>
<TD width="25%">Time of day</TD>
<TD width="25%">Food</TD>
<TD width="25%">Drink</TD>
<TD width="25%">Time allotted for meal</TD></TR>
<TR>
<TD width="25%">6 am</TD>
<TD width="25%">Eggs</TD>
<TD width="25%">Juice</TD>
<TD width="25%">30 minutes</TD></TR>
<TR>
<TD
width="25%">11am</TD>
<TD width="25%">Sandwich</TD>
<TD width="25%">Water</TD>
<TD width="25%">30 minutes</TD></TR></TABLE>
Corrected HTML – EXAMPLE 5
The corrected HTML example contains the axis attributes.
<TABLE
cellSpacing=0 cellPadding=4 width="100%" border=1>
<TR>
<TH id="header9" width="25%">Time of day</TH>
<TH id="header10" width="25%">Food</TH>
<TH id="header11" width="25%">Drink</TH>
<TH id="header12" width="25%">Time allotted for
meal</TH></TR>
<TR>
<TD
axis="header9" width="25%">6 am</TD>
<TD axis="header10" width="25%">Eggs</TD>
<TD axis="header11" width="25%">Juice</TD>
<TD axis="header12" width="25%">30
minutes</TD></TR>
<TR>
<TD axis="header9" width="25%">11am</TD>
<TD
axis="header10" width="25%">Sandwich</TD>
<TD axis="header11" width="25%">Water</TD>
<TD axis="header12" width="25%">30
minutes</TD></TR></TABLE>
Example six demonstrates the correct use of row grouping.
Current HTML – EXAMPLE 6
The current HTML example does not use row grouping
<TABLE
cellSpacing=0 cellPadding=4 width="100%" border=1>
<TR>
<TD width="25%">Time of day</TD>
<TD width="25%">Food</TD>
<TD
width="25%">Drink</TD>
<TD width="25%">Time allotted for meal</TD></TR>
<TR>
<TD width="25%">6 am</TD>
<TD width="25%">Eggs</TD>
<TD width="25%">Juice</TD>
<TD width="25%">30 minutes</TD></TR>
<TR>
<TD width="25%">11am</TD>
<TD width="25%">Sandwich</TD>
<TD width="25%">Water</TD>
<TD width="25%">30 minutes</TD></TR></TABLE>
.
Corrected HTML – EXAMPLE 6
The corrected HTML example uses row grouping as required.
<TABLE
cellSpacing=0 cellPadding=4 width="100%" border=1>
<thead>
<TR>
<TH width="25%">Time of day</TH>
<TH width="25%">Food</TH>
<TH width="25%">Drink</TH>
<TH width="25%">Time allotted for meal</TH></TR>
</thead>
<TBODY>
<TR>
<TD width="25%">6 am</TD>
<TD width="25%">Eggs</TD>
<TD width="25%">Juice</TD>
<TD width="25%">30 minutes</TD></TR>
<TR>
<TD width="25%">11am</TD>
<TD width="25%">Sandwich</TD>
<TD width="25%">Water</TD>
<TD width="25%">30 minutes</TD></TR>
</TBODY>
</TABLE>
The demo file for this section can be downloaded from the
internet
http://understandingaccessibility.com/
Remember to follow along in your Web page editor you must
first download the example. To do this: Open the above page in Internet
Explorer and save it locally by completing the following steps.
- Open the above page in your browser
- Select File |Save As
3. Type in
fpdemoframes.htm or fpdemoframesfixed.htm in the filename input box, make sure
you selected to save as complete web page so you will have all demo files.
4. Click on the Save
button
If you purchased the eBook these files were included in
a zip file called demos.zip. Extract this file to your hard drive.
Now open the saved file in your Web page editor and we are
ready to begin.
The accessibility issues that will be covered by section six
are:
- All Frame Elements are required to contain the title
attribute
- All Frameset Elements are required to contain the noframes
element
Example one demonstrates how to use FRAME title attributes.
Current HTML – EXAMPLE 1
The current HTML does not implement the title attribute
<FRAMESET
cols="40%,60%">
<FRAME
src="left_frame.htm">
<FRAME
src="right_frame.htm" >
</FRAMESET>
Corrected HTML – EXAMPLE 1
The corrected HTML implements the title attribute
<FRAMESET
cols="40%,60%"
title="Our
product line">
<FRAME
src="left_frame.htm"
title="Frame
Left:
Navigating
our web">
<FRAME
src="right_frame.htm"
title="Frame
Body: Body text">
</FRAMESET>
Example two demonstrates how to use the NOFARMES element.
Current HTML – EXAMPLE 2
The current HTML does not implement the NOFRAMES element.
<FRAMESET
cols="40%,60%"
title="Our
product line">
<FRAME
src="left_frame.htm">
<FRAME
src="right_frame.htm" >
</FRAMESET>
Corrected HTML – EXAMPLE 2
The corrected HTML implements the NOFRAMES element.
<FRAMESET
cols="40%,60%"
title="Our
product line">
<FRAME
src="left_frame.htm">
<FRAME
src="right_frame.htm" >
<NOFRAMES>
This
page uses frames, but your
Search
engine or Web browser may not
support
them.
<A
href="products.html" title="Products link">
Select here to go to the
products page</A>
</NOFRAMES>
</FRAMESET>
HTML With NOFRAMES Element Added and
Title Attribute
The below corrected HTML makes the Frameset completely
accessible.
.
<FRAMESET
cols="40%,60%"
title="Our
product line">
<FRAME
src="left_frame.htm"
title="Frame
Left:
Navigating
our web">
<FRAME
src="right_frame.htm"
title="Frame
Body: Body text">
<NOFRAMES>
This
page uses frames, but your
Search
engine or Web browser may not
support
them.
<A
href="products.html"
title="Products
link">
Select here to go to the
products page</A>
</NOFRAMES>
</FRAMESET>
The demo file for this section can be downloaded from the
internet
http://understandingaccessibility.com/
Remember to follow along in your Web page editor you must
first download the example. To do this: Open the above page in Internet
Explorer and save it locally by completing the following steps.
- Open the above page in your browser
- Select File |Save As
3. Type in fpdemo6.htm in
the filename input box, make sure you selected to save as complete web page so
you will have all demo files.
4. Click on the Save
button
If you purchased the eBook these files were included in
a zip file called demos.zip. Extract this file to your hard drive.
Now open the saved file in your Web page editor and we are
ready to begin. This section covers the most common forms of screen flickering.
If you want more information on this requirement refer to Chapter Two of this
book. The accessibility issues that will be covered by section seven are:
- Documents are required not to contain the BLINK element
- Documents are required not to contain the MARQUE element
Example one demonstrates alternatives to the BLINK element.
Current HTML – EXAMPLE 1
The current HTML uses the BLINK element to allow the user
agent to blink (flash the Message) repeatedly signifying the importance of the
text to the user.
<blink>Pay
attention to this</blink>
Corrected HTML – EXAMPLE 1
The corrected HTML does not use the BLINK element instead it
implements other formatting to show the importance of the text.
<strong><u>Pay
Attention to
This</u></strong>
Example two demonstrates alternatives for the MARQUEE
element.
Current HTML – EXAMPLE 2
The current HTML uses the MARQUEE element to scroll a
message across the screen; this is intended to catch the users attention.
<marquee
align="bottom" bgcolor="#C0C0C0"
direction="right" scrolldelay="91" width="100%"
height="16">
use
of
Marquee can cause you to fail Accessibility testing
</marquee>
Corrected HTML – EXAMPLE 2
The corrected HTML uses alternative methods of making the text
grab the users attention.
<em><strong><u>
use of
Marquee can cause you to fail Accessibility Testing
</u></strong></em>
The demo file for this section can be downloaded from the
internet
http://understandingaccessibility.com/
Remember to follow along in your Web page editor you must
first download the example. To do this: Open the above page in Internet
Explorer and save it locally by completing the following steps.
- Open the above page in your browser
- Select File |Save As
3. Type in fpdemo7.htm in
the filename input box, make sure you selected to save as complete web page so
you will have all demo files.
4. Click on the Save
button
If you purchased the eBook these files were included in
a zip file called demos.zip. Extract this file to your hard drive.
Now open the saved file in your Web page editor and we are
ready to begin. The accessibility issues that will be covered by section eight
are:
Ensure that pages are usable when
scripts, applets, or other programmatic objects are turned off or not
supported. If this is not possible, provide equivalent information on an
alternative accessible page.
·
Anchor
elements are required not to use javascript for the link target when the
NOSCRIPT element is not present in the document body.
·
AREA elements are required not to use javascript for the link
target when the NOSCRIPT element is not present in the document body.
·
When SCRIPT Elements are used, the NOSCRIPT element is required
in the document body.
Example one demonstrates the proper usage of the NOSCRIPT
element
Current HTML – EXAMPLE 1
The current HTML uses the script element that can be used to
open another browser window. This is used to present the user with an offer.
<SCRIPT
language="JavaScript">
<!--
function popwin(){
window.open('http://www.undersyandingaccessibility.com/acctest.htm','','width=400,height=200,
scrollbars=1');
} // -->
</script>
Corrected HTML – EXAMPLE 1
The corrected HTML uses the NOSCRIPT element for the SCRIPT
element. This assures that users who do not have a browser that supports
scripts receive the same offer.
<SCRIPT
language="JavaScript">
<!--
function popwin(){
window.open('http://www.undersyandingaccessibility.com/acctest.htm','','width=400,height=200,
scrollbars=1');
} //
--> </script>
<noscript>
This pages used JavaScript to display a pop-up window that points a user to
<a href="http://trial.accessibilitywatch.com/scripts/tryaccwmh.exe"
class="thenav">WebSite Accessibility
Testing and Repair Solutions trial</a>
This link is for a trial
of the web site accessibility testing service</noscript>
Example two demonstrates how to correct ANCHOR elements that
use script.
Current HTML – EXAMPLE 2
The current HTML uses a JavaScript function to navigate
within an ANCHOR element. This is unwise and should not be done.
<a
href="javascript:displayWindow('sample.htm',360,145)">
Corrected HTML – EXAMPLE 2
The corrected HTML uses a direct link to the page.
<a href="http://www.undersyandingaccessibility.com/sample.htm">
NOTES – EXAMPLE 2
Using JavaScript in your anchors could work for most
visitors, however, the complexity of the NOSCRIPT element should deter you from
doing this. It is recommended to NOT USE JavaScript in ANCHOR elements.
Example three demonstrates how to correct AREA elements that
use script.
Current HTML – EXAMPLE 3
The current HTML use
