- From: <kelly@ripco.com>
- Date: Tue, 06 Mar 2001 12:45:39 +0100
- To: w3c-wai-ig@w3.org
These are the accessibility standards Fleet Boston has agreed to adhere to
as part of the settlement agreement requiring accessible services for
blind persons. The agreement is for fleet.com and not other operating
units, such as the Quick and Reiley brokerage and Suretrade.com.
kelly
URL: http://www.dlc-ma.org/atm/atmea.htm
Exhibit "A" to Agreement
FleetBoston Web Accessibility Standards
December 1999
Charmian Proskauer, Website Management Group
Marie Meibaum, Internet Technology Support
Last updated February 2001
Charmian Proskauer, Website Management Group
The issue of Web accessibility has become a high priority as web pages
become more complex.
The World Wide Web Consortium (W3C) has defined accessibility
guidelines and a checklist for Web Site developers. The W3C guidelines
have checkpoints in 3 Priority categories, with the Priority 1's being
the most critical to follow rules. FleetBoston has made a commitment
to meet all Priority 1 and Priority 2 checkpoints. FleetBoston will
include web accessibility as one of its criteria in its future RFPs
and other procurement documents, and vendor contracts.
The website http://www.w3.org/TR/WAI-WEBCONTENT/ gives further
information on these guidelines and their associated checkpoints, and
should be considered the authoritative source for accessibility in
Fleet's web design and development.
This document is a summary of the key W3C Web Content Accessibility
guidelines, and for the convenience of Fleet's designers, content
managers and web developers, has been organized into presentation
rules, content rules and programming rules. It also includes a section
on guidelines for testing and a section on notes on specific
accessibility practices for FleetBoston's websites. Please refer to
the W3C guidelines for more detail.
Presentation (Designer) Considerations
Design Principles
The high-level design rules to be followed to stay in compliance with
our requirements for web site accessibility, and to conform to all the
W3C guideline category 1 and 2 checkpoints:
* Design for clear understanding when a screen reader is used.
* Provide text equivalents for images, animations, applets,
scripts, buttons, hyperlinks, and audio.
* Design with high color contrast.
* Don't use color as the only means to convey information.
* Clean bold design.
* Acceptable font size for low vision viewers.
* To the extent possible, font size should be controllable by the
user.
* The screens and forms should allow for navigation and activation
without a mouse.
* Each field in a form should have a label. Data formats should be
clearly specified. Error messages should display above the form.
Use HTML H1-H6 to Identify new sections for presentation. These can
be used in conjunction with "HR".
Do not use "BLOCKQUOTE" for indenting, or horizontal rule "HR" for
presentation purposes.
Standardize page design for templating.
Future plans may include using databases and files for content.
Do Not Use (W3C guideline #)
Do not allow screen to have anything that flickers. (7.1)
Do not convey information with color alone. (2.1)
EXAMPLE: To highlight or flag a piece of information with RED to
indicate a negative point, as opposed to a GREEN highlight or flag to
indicate a good point.
ISSUE: When page is read through a screen reader, or printed, or read
by a colorblind person, this information is lost.
Content Designer Considerations (W3C guideline #)
Use clear and simple language in the site content. Avoid technical
terms. (14.1)
2. Add an Accessibility instruction page similar to the one found at
http://www.ci.san-jose.ca.us/access.html. Link this page to all
section home pages.
3. When using PDF's, check to ensure that text version is
understandable to a screen reader; if not, include option to choose
HTML or text instead of PDF. If appropriate, include alternate method
for obtaining document or form.
4. Provide an auditory description of the important information of a
multimedia presentation. (1.4)
* Synchronize equivalent alternatives for time-based multimedia
presentations. (1.3)
5. Alt-tags should be provided for all image-based text elements that
convey meaningful information (1.1). In most cases, the text of the
alt-tag should match the text in the image. In the case of very long
image-based text (paragraph or more) where a long alt-tag would
obscure the text, the alt-tag may summarize the content of the
image-based text (this should be an exceptional case).
Programming Standards (W3C guideline #)
Note to web developers: Please refer to W3C Techniques (referenced
with each checkpoint) for specific coding examples.
1. All graphics containing text or other information content must have
a descriptive "Alt" tag or "longdesc". (1.1) Please see #5 in Content
Designer Considerations above.
* Include "alt" tags on all Hyperlinks in an image map.
* Include descriptive explanations of images if they convey essential
information.
* Include descriptive tags on animated images if they convey essential
information.
* Use text descriptions with graphs, charts, and symbols.
2. Setup Image maps to run on the client side. Use "alt" tags to
describe the general purpose of the map and on all hyperlinks.
* Use client-side image maps with descriptive text.(9.1)
* Use client-side image maps whenever possible, instead of
server-side. If a server-side image map is necessary, provide
redundant text links for each active region. (1.2)
3. Use "summary" and "caption" to describe tables. Describe each
column and content. (5.1)
4. Use text for hyperlinks that makes sense when read out of context.
* Do not use Click here; instead use Learn more about, etc.
* Add descriptive "alt" to hyperlinks. If the hyperlink is under a
specific heading, a blind person hearing the page through a
synthesizer, might not realize the context, so more details should
be given in the "alt" tag.
5. Check navigation and form usage for non-mouse access.
* Include keyboard scrolling, an alternative to buttons, and popup
windows.
* Include adequate instructions for non-mouse users.
* Make sure tabbing in a logical order and tabbed fields are visible.
* Provide short-cut key alternatives for pull-down menus.
6. When using PDF's, check to ensure that text version is
understandable to a screen reader; if not, include option to choose
HTML or text instead of PDF. If appropriate, include alternate method
for obtaining document or form. (Please see "Use of PDF format files"
in the Notes on Practices section below for further clarification.)
7. Title each frame to facilitate frame identification and navigation.
8. Ensure that pages are usable when scripts, applets, and
programmatic objects are turned off or not supported. If another
equivalent page is needed, make sure text changes are kept current on
the alternate page. (6.3)
9. Use caption tag to describe any text not in natural language. (4.1)
Use for foreign language fragments.
Notes on Practices on the www.fleet.com site
Use of PDF format files
In some instances reference information, including print-and-mail-in
forms, are provided on the site in PDF format. All hyperlinks to PDF
documents will include the word "PDF" within the hyperlink
description. It is Fleet's decision that only the PDF version of the
file will be posted on the site. This will eliminate the maintenance
problem of keeping both a PDF and a text version of the PDF up to
date, and likewise will eliminate visitor uncertainty about whether
the text version is current. However, all PDF files will be tested
prior to posting to determine that they convert to text properly.
Instructions will be posted prominently on the site with a link from
each page where a PDF is posted that describe how to view the PDF in a
text format. If needed, an alternate method for obtaining the document
or completing the form will be provided. PDF documents depicting
information which by their very nature are graphical, such as street
maps, building plan drawings, and pictorial diagrams, are exempt from
this Accessibility requirement.
Scripts and Java applets
Reasonable efforts will be made to provide accessible versions of all
scripts and applets. In rare instances where a script or Java applet
is not usable by a screen reader an alternative means of accessing the
information, such as a Customer Service telephone number, will be
provided.
Third Party provided content
Third party provided content will be tested for accessibility. In
cases where improvements are needed, vendors will be directed to make
the necessary changes.
Maps
Graphics which contain information that is by nature purely graphical,
such as maps, will be exempted from the accessibility requirement. If
possible, an alternate presentation of the information, such as
driving directions, will be provided. For convenience of screen
readers, an alt-tag of "map" or " " can be used to suppress undesired
information associated with the map, such as the database reference.
Help
Where needed, instructions specifically for screen reader users will
be provided.
Testing for Accessibility
Fleet has committed to an active accessibility testing program.
Testing will occur during the design/development and acceptance
phases.
Testing Tools
Compatibility with screen readers will be the primary accessibility
standard.
* JAWS for Windows v 3.5, WindowEyes v 3.1 (with IE 5.0) - will use
these or current shipping versions for testing. JAWS is the primary
screen reader used.
* Some features may not work with older versions of screen readers,
but we will not attempt complete backward compatibility
* At least one format or presentation of content on the page will
be rendered usably. The page will render in an understandable and
logical fashion; links, input forms, and other functional elements
will be usable with JAWS commands.
Other Accessibility Testing Procedures
* Assess the page from low vision perspective (sufficient contrast,
adequate font size).
* Check for "color-blind" color combinations.
* In Internet Explorer, turn off graphics and view the page. Check
for alt-tags and long-descr.
* Try navigating the screen without a mouse. Make sure tabbing is
logical, and screen is usable without a mouse.
* Use browser settings to enlarge fonts.
* Use a tool to search for links (e.g. LINKBOT). Ensure links make
sense independent of context (i.e. not "click here").
* Any new functions/features not already "qualified" for use with
screen readers should be tested using a screen reader, then
submitted to an independent tester for further review.
_________________________________________________________________
Received on Tuesday, 6 March 2001 06:45:42 UTC