To Next Section - Overview
To Table of Contents
This page provides a quick reference of the ideas
you should consider while designing HTML pages to maximize
the number of users that can view then TODAY. This includes people
with text-based browsers, people with slow (modem) connections,
people without A/V capabilities, people with helper applications
missing, and people with disabilities. The goal is to make pages
accessible while maintaining or increasing their attractiveness.
Several strategies are suggested for each area to allow you to
select a strategy or combination of strategies that match your
needs.
Three alternate strategies which can also be used together.
Note: It is possible to embed text descriptions in some picture formats such as JPEG. Someday, external viewers will be available which allow you to view either the picture or the description from such formats - if the text description is there. It is a good idea to include it now - but it is not sufficient for access yet.
Maintain a link to a page with a transcript or description of the sound file. Use a phrase such as "or a transcript of xxxx" or "hear the speech or read the transcript" with "read the transcript" acting as the link to the transcript.Note: Someday audio file formats and players may include the ability to handle text as part of the sound file.
Note: If the movie format permits multiple video tracks then a secondary video track with an interpreter signing American Sign Language could also be provided.
Note: Client side image maps are rapidly coming to the fore. As soon as a standard is defined and non-image modes of graphic browsers support them this will be another solution strategy. Currently, LYNX displays the text descriptions for each URL in a client side image map. Text descriptions are defined with alt attribute of the USEMAP tag.
Note: To make edit boxes
accessible by users viewing pages with screen readers, some sites
are experimenting with place-holding information in edit boxes,
like short descriptions or cues, so that screen readers can detect
the presence of the edit boxes. Screen reader and browser designers
are also addressing this problem.
Tables cause problems for screen reading software (used by people who are blind) since the screen readers tend to read across the screen in a way that runs all of the text on a line together. If an entry in a cell occupies more that one line the first line of each cell would be read, then the second etc.Solutions today
No good solutions exist at this time. If you can, avoid using TABLE structures. You could also present the data on an alternate text-only page without tables. Work is in progess on this problem, including screen readers that can read by columns.
OR Provide an alternate text-only page which translates all of the information included in the original page to text only. This can provide a fast access method for all users. Users should be able to switch back and forth between text-only and graphic versions of the page.
Avoid non-standard data structures and viewers. The only way for custom data and views to be accessible is if the access is built directly into the viewer. Standard access tools do not generally work with special viewers.
Always test your pages using a variety of text browsers and platforms (PC, MAC, UNIX). Be sure to include text-based browsers and use graphic browsers with images turned off.
Appendix B
Experimental solutions and discussion of d-tags, alt-text, text anchors, forms, and edit boxes.
To Next Section - General Comments
To Table of Contents
When discussing the accessibility of the World Wide Web, it is important to break the problem down into the three basic components:
Making the WEB accessible or usable by people with disabilities
involves all three components. This document focuses on things that can
be done when creating HTML pages (source documents), but also
mentions strategies that might be used at other levels now or
in the future to provide context and a look forward. In some cases,
problems which are difficult to address today at the source document
level may be easily addressed with changes in the pipeline or
viewers.
Making HTML Documents Accessible TODAY
There are some features of the World Wide Web (WWW) which are
not currently accessible to people with some disabilities using
today's browsers (such as Mosaic, Netscape, Microsoft's
Internet Explorer, AOL net browser etc.). In addition, many of the data
formats currently do not support accessibility annotations (captions,
vocal and text annotations, etc.). As a result, if you want to
create WWW documents that will be accessible to people with disabilities
TODAY you need to either avoid using some features and data types
or provide alternate methods for carrying out the functions or
information provided through the inaccessible functions.
In the future, alternate access methods for the standard features may be built directly into WWW browsers, as well as the standard data storage and transmission formats, making it unnecessary to avoid features or build redundant mechanisms into your HTML documents. Until these alternate access features and standards are developed however, care must be taken in the design of HTML pages if they are to be accessible to users with disabilities
To Next Section - In-Line Graphic Elements, Pictures, and Diagrams
To Table of Contents
It is possible today to make WWW (HTML) documents that are accessible
by simply avoiding the aspects of HTML or WWW browsers which cause
the access problems. For example, if you create a document which
ONLY has text and hypertext links (no graphics or sounds), then
you will have a document which can be accessed by most anyone
with a disability using a personal computer that has been adapted
for their use. Although this is a rather elementary and restricted
use of HTML, it is nonetheless a viable approach, as
is using gopher and ftp.
However, a WWW/HTML document does not need to limit itself to
text to be accessible. There are a number of strategies that can
be used to allow use of graphics and sound while still maintaining
accessibility.
- Some of these strategies require changes in either the WWW servers or viewers such as Mosaic.- Other strategies, however, do not require any changes and can be used today.
Below are some of the strategies from both categories.
Problems in access to HTML fall into seven basic areas:
To Next Section - Separate Viewer Based Graphic Elements
To Table of Contents
The problem:
Solution Strategies
Today there is such a feature for in-line graphics. It is an option
within the IMG definition and allows authors to attach an alternate
text description to any in-line graphic. It is commonly referred
to as ALT-TEXT.
The form for this is:
<A HREF = "http://www.your.host/filepath/filename"> <IMG SRC="http://www.your.host/filepath/filename.gif" ALT="Alternate text describing the picture."></A>
The latest versions of Mosaic and Netscape support this strategy
as do the text-based browsers like Lynx and DOSLynx (whose developers
at the University of Kansas introduced this convention). In the
future it is probable that most or all graphic browsers will also
support this feature.
This approach does not actually allow text descriptions to be
included (and called up separately from) the picture data file,
and it does not address the problem for graphics which are NOT
embedded in the text (which is covered in the next section). It
does however provide a mechanism for attaching text descriptions
to in -line graphics (pictures that are displayed as part of
the HTML page.
The ALT-TEXT approach is very effective in most layouts - and
is recommended for all in-line graphics. However, on some pages
with unusual layouts, it may result in pages which are confusing.
In this case it is recommended that you ALSO create a separate
"text-only" version of the page which eliminates the
use of graphics. In general, however, this makes it a bit more
complicated to maintain your pages since edits must always be
done to two pages when edits are needed. (If your pages are generated
from a database "on the fly" this problem would not
exist - but your page generation software would need to include
this capability)
Today, therefore, you can/should use one of these five approaches. A combination of the first 3 approaches is probably the most effective:
Approach 1-1: ALT-TEXT:
Provide ALT-TEXT which would be displayed instead of the image when the image is not displayed (e.g. when viewing the page with a text-only browser, or with the "auto load images" feature turned off. (See above for format) [See also Picture Description Below]
Approach 1-2: Description page
By their nature, ALT-TEXT descriptions are usually short and define the basic purpose of graphic elements. For example "Logo for XYZ company" or "Picture of ZZZ Center Building". These are instructive but do not provide very much information about the pictures.
In order to provide people who are blind with additional information WGBH has pioneered the practice of placing a capital "D" text anchor next to pictures or graphics which links to a longer description of the graphic. For example, "The Logo for XYZ company consists of a globe with people of different races all standing out from the globe holding hands while a sunburst shines from behind the earth. The earth is positioned so that no particular continent is centered on the globe" Descriptions which are too long for ALT-TEXT descriptions can thus be provided... yet do not clutter up the main page.
Since the "D-tag" is not a very descriptive link, if you use this method you should probably include a statement somewhere that describes what access features you have included so that people know that a capital "D" will take them to a description of an image. Another option is to use a more descriptive text anchor, such as "or a description of xxxx".
Approach 1-3: Alternate pages:
Provide a second version of the page which does not include any in-line pictures for decoration or for anchors. Instead, text descriptions and anchors would be used. If this is done a note at the bottom of each page could allow users to move back and forth between the graphic and text-only versions of the page. It is still recommended that you provide the ALT-TEXT tags described in approach 1-1 on your 'graphic version' of the page. It is easy to see that creating text-only versions of every page on a site doubles the number of pages that need to be maintained. Here are three methods for generating and maintaining text-only pages.
Method 1-3.1: "By hand" Sometimes, a site may only need to create text-only pages for layouts that can not be made accessible. This may only involve a couple of pages.
Method 1-3.2: Database-based pages:
Create a database-based server that generates HTML pages on demand when the user asks for them. In this manner, pages can be constructed "on the fly" either with or without graphics. An example of this is the CommerceNet server.
Method 1-3.3: Filter
This approach is similar to Method 1-3.2, but involves the use of a filter/translator that would exist on the server as a common gateway interface (cgi). Pages would be constructed using ALT-TEXT and alternate text pages where needed and, at the direction of the user, translated into either graphic or pure text pages on the fly. This method has disadvantages however. Since all pages must be processed on the fly (as with the database method), there may be a performance hit unless the filter program is used off-line to create the text versions of the pages in advance. Secondly, this method would only work for pages on the server with the AltPage cgi. Whenever references were made to other pages on other servers, the filter would not work. Image Maps on other servers would be a particular problem unless client side image maps were used. Finally, such a filter would create text versions of pages, but since it would do it by formula, the pages may not be laid out very well or be very easy to interpret. Building access into the page or providing alternate pages which are laid out to make sense in text form (and to provide a text alternative to any Image Maps) as with Method 1-3.1 would be much more effective.
Approach 1-4: Embedded text descriptions:
Incorporate both the graphic AND TEXT within the anchor. The ALT-TEXT text should also be included for those browsers that support it. The format would be:
Recommended format today:
Running text on the page <A HREF="http://www.your.host/path/filename.html"> <IMG SRC="http://www.your.host.path/filename.gif" ALT="Text describing picture.">running text that could serve as an anchor instead of or in addition to the in-line picture </A> rest of running text....
An example:
The newest product in our line is the <A HREF="http://www.xyz.com/products/magicom.html"> <IMG SRC="http://www.xyz.com/products/images/magicom.gif" ALT="[Picture of Magicom Phones]"> Magicom portable phone</A>, the world's smallest portable pocket phone.
which yields:
The newest product in our line is the[Picture of Magicom Phones] Magicom portable phone, the world's smallest portable pocket phone.OR
The newest product in our line is the <A HREF="http://www.xyz.com/products/magicom.html"> Magicom portable phone <IMG SRC="http://www.xyz.com/products/images/magicom.gif" ALT="[Picture of Magicom Phones]"></A>, the world's smallest portable pocket phone.
which yields:
The newest product in our line is the Magicom portable phone, [Picture of Magicom Phones] the world's smallest portable pocket phone.
To Next Section - Audio
To Table of Contents
The problem:
Often in viewing HTML pages, users will encounter images or anchor
phrases which will fetch and display a large graphic image. This
image is often displayed using a separate viewer in a separate
window on screen.
Solution strategies in the future
Someday, all graphic data formats (such as TIFF, JPEG, PICT or
their successors) will also allow incorporation of text describing
the image (very useful for access and for searching or indexing
pictures). External or "Helper" viewers could then allow
display of the graphic, its text, or both. Servers could also
be able to send the graphic portion, the text version, or both,
on request from the browser. (Java applets could be programmed
to do this today but it is not a general capability yet.)
Solutions today
Until this occurs, however, the only known approach for providing
alternate text for NON-EMBEDDED GRAPHICS is to provide an alternate
data file with the text description of the graphic in it. (Although
some graphic storage formats do allow storage of text within the
data structure, the servers, browsers, and viewers do not yet
allow access to it.)
Approach 2-1: (generally recommended)
Place an anchor to a separate page which has a text description of the picture right next to the anchor that pulls up the picture.
As discussed in the last section, WGBH has instituted the practice of putting a capital "D" next to pictures or graphics in a document. If you are using a thumbnail version of the picture as an anchor to the larger picture, you could use the "D"-tag very effectively for the anchor to the description of the picture.
Approach 2-2:
Include a descriptive text anchor to a page describing the graphic. For example: "or a description of xxxx".
Approach 2-3:
If the user has requested a text-only page, replace all references to pictures with references to the text files describing them.
In general, Approach 2-1 is preferred since many users may have
asked for the text-only version because of speed, and may want
to view occasional pictures of interest. Also, even blind users
may sometimes want to pull up a picture to show someone, or to
have someone describe it to them in more detail. Both of these
are much easier with approach 2-1 than with 2-3.
To Next Section - Movies
To Table of Contents
The problem:
Solution strategies in the future
The problems and solution strategies for audio clips are very
similar to those for separate viewer-based
graphic elements (Problem
Area 2) and movies (Problem Area 4):
Solutions today
The strategies for accessing sound today also look essentially
the same as for graphic files:
Access is provided by having a separate file with a transcript
of the speech or description of the sound. This separate file
is accessed in one of two ways:
Approach 3-1: (generally recommended)
Place an anchor to a page with a text transcript or description of the sound right next to the anchor for the sound.
Approach 3-2:
If the user has requested a text-only page, replace all URL references to sound with URL references to the text transcript or description.
As before, Approach 3-1 is preferred because it provides the user
with more options, allows them to use any residual hearing, and
is useful to people with language impairments.
It is often the case that people without disabilities are interested
in the text transcripts as well.
Example:
Below is an example based on the White House Web server, courtesy
of Paul Fontaine at the General Services Administration. Note
that this example includes both ALT-TEXT access to the sound icon
(audio.gif) (for users who are using text browsers or screen readers)
and the text translation (al_npr_intro.html) of the audio file
(gore.au) (for users who cannot hear or do not have audio capabilities
on their computers).
Suggested code:
The President asked <A HREF="http://www.ostp.eop.gov/images/raw/al-portrait.gif> <IMG SRC=http://www.ostp.eop.gov/images/small/al-portrait.gif" ALT="[Picture of Al Gore]">Vice President Gore</A> to head up the <A HREF="http://www.npr.gov/">National Performance Review (NPR)</A), a project to make government work better and cost less. You can <A HREF="http://www.ospt.eop.gov/sounds/gore.au"> <IMG SRC="http://www.ostp.eop.gov/icons/audio.gif" ALT="[Sound Icon]">hear</A> or <A HREF="http://www.npr.gov/al_npr_intro.html">read</A> Mr. Gore's speech introducing NPR.
This would look like:
The President asked [Picture of Al Gore] Vice President Gore to head up the National Performance Review (NPR) a project to make government work better and cost less. You can [Sound Icon] hear Mr. Gore's speech introducing NPR or read a transcript..
To Next Section - Image Maps
To Table of Contents
The only known way to make movies accessible to people with disabilities
is to embed the accessibility information in the data stream so
that it is time-synched with the other information.
Two types of alternate format information are needed to make video
accessible:
Audio: Captions or other visual representations of all important information in the sound track should be provided. (Some data structures such as QuickTime movies already have a mechanism for adding captions to the data structures.)
Video: For people who are blind or who have low vision, a technique called Descriptive Video is used which provides an additional narrator describing what is happening, in between the regular dialog of the movie.
Text transcripts should be provided for both Audio and Video for
users with text-based browsers and/or no helper apps.
Solution strategies in the future
Eventually, all data structures should allow captions and audio
or text descriptions of movies to be embedded in the data storage
and transport formats.
Servers should allow any combination of video, audio, caption,
or description to be fetched on command.
Viewers or players (helper applications) should allow users to
specify and display any combination of the above.
Solutions today
Captions (for those who do not have access to sound)
Approach 4-1: (Recommended)
If the external viewer being used will display "closed" or embedded captions (e.g. Quicktime) , captions can be embedded in the data structure of the movie.
Approach 4-2: (Good Alternate)
A strategy which works for all movie viewers today is to have an alternate version of the movie available with open (permanent) captions which a user can choose instead of the uncaptioned version if they wish.Approach 4-3: (Good as supplement)
In addition to providing captions in the movie, it is also useful to provide a separate transcript of the audio track of the movie. It usually takes quite a while to download a movie file, and a text transcript of the audio can usually be downloaded quickly and allow one to prescreen the item before deciding whether to take the time to download it.
Descriptive Video: (For those who cannot see the video portion of the movie)
Approach 4-4: If the movie format allows alternate audio tracks (e.g. QuickTime) you can provide an alternate track which includes the descriptive narration.
Approach 4-5: If your movie format does not, you can provide an alternate form of the movie with the descriptive narration included in the audio track.
Approach 4-6:
In addition to providing a transcript of the basic audio track of the movie, it is also useful to include the text of the Descriptive Video in the transcript.
Example - Quicktime
In Quicktime you can add as many Audio or Video Tracks as you
wish. The user can then select as few or many of the tracks as
desired when they view the Quicktime Clip.
Tracks could include
Other Advantages
In addition to the access advantages of these approaches, there
are also other benefits as well.
To Next Section - Forms
To Table of Contents
Problem:
Image maps allow users to click on "hot spots"
of a picture which reference WWW pages. This type
of feature, which requires an ability to see and click on particular
parts of a graphic image, is completely inaccessible to people
who are blind. Even if the picture is described, they are unable
to detect where to click.
Image maps are used in a wide variety of ways. Some uses are rather
simple like nice looking menu bars. Others
are more sophisticated, like graphic representations of maps,
diagrams, etc.
Solution strategies in the future
"Client Side" image map capabilities are beginning to
be introduced in browsers though no standard approach has yet
been agreed upon. "Client Side" image maps are similar
to regular image maps except that the information regarding all
of the links or "hot spots" on the image are sent to
the browser along with the image map picture. If descriptions
(a sort of "ALT-TEXT" for the image maps links) are
provided with the URLs, then browsers can be designed which would
give a user the choice between the graphic image map or a descriptive
listing of the choices normally provided by the image map - in
all text format.
Solutions today
Today, there are three strategies for providing access. All of
them involve ways to provide an option for a text-only version
of the image map's choices, usually as a listing of
text anchors.
Approach 5-1:
Next to (or just below) the Image Map graphic, provide a text anchor which will take you to a new page with the text listing of the Image Map URLs on it. This is easy, but removes the listing from the context of the rest of the page. As a result this approach is not generally recommended.
Approach 5-2: (recommended)
Have an anchor to a text-only page which presents an alternate form of the entire page. Replace the image map with a list of text anchors of the URLs available through the image map.
Approach 5-3: (also good if done in a way which avoids confusion)
Provide a listing of image map choices as a list of text anchors immediately below the image map. This sometimes works, but can also be confusing. The ALT-TEXT of the image map should say that choices are provided in text form following the image map.
See appendix for experimental approaches and discussion.
To Next Section - Tables
To Table of Contents
Problem:
Some HTML pages include forms constructs. At the present time
it is difficult for screen readers and some browsers to handle
some forms elements. Further research is being conducted in this
area.
Solution strategies in the future
In the future, features within the browsers will allow users to
display forms elements in a way that screen readers can access
them.
Solutions today
For now the best idea would be to provide a form which can be
downloaded then mailed or e-mailed, or a phone number someone
can call to provide the requested information. To make edit boxes
accessible by users viewing pages with screen readers, some sites
are experimenting with place holding information in edit boxes,
like short descriptions or cues, so that screen readers can detect
the presence of the edit boxes.
(Additional, more specific information on both the problems and
strategies for different browsers will follow for this area.)
To Next Section - Non-Standard Formats
To Table of Contents
Problem:
Tables cause problems for screen reading software
(used by people who are blind) since screen readers tend to
read across the screen in a way that runs all of the text on a
line together. If an entry in a cell occupies more that one line
the first line of each cell would be read, then the second etc.
Solution strategies in the future
It has been proposed that the table construct will contain two
attributes that will help people using screen readers access information
in tables. These are the AXES and AXIS attributes that would be
associated with each cell in the table. Thus for each entry in
the table the row and column information as well as the cell's
data contents would be available to the screen reader.
Solutions today
No good solutions exist at this time. If you can avoid using the
TABLE structure that is best. You could also present the data
on an alternate text page without tables. Work is in process on
this problem.
To Next Section - Custom Data Structures and Viewers
To Table of Contents
Problem:
As HTML evolves, new flexibility is being introduced. Tables and
other constructs allow text to be laid out in side by side paragraphs
and other formats which cause difficulties for screen readers
which will usually read a row in a table as a sentence.
For Microsoft Windows, browsers could be designed to use child
windows for each place in the table, and render into the child
windows. Doing this would allow screen readers to interpret the
page layout and develop techniques to navigate through the table
hierarchy.
Solution strategies for today
8-1: Keep layouts simple and straightforward
8-2: Avoid side by side presentation of text
8-3: Avoid using graphics to provide organization or structure to the document. Use HTML.
8-4: Where following guidelines 8-1 to 8-3 would interfere with the presentation of the information for some reason, a text-only page which presents the same information in an accessible format could be used.
To Next Section - Color
To Table of Contents
Problem:
Some web sites are introducing special data structures and viewers
to differentiate themselves or provide special functions not available
with the standard tools.
Solution Strategies
The only way for these custom data and views to be accessible
is if the access is built directly into the viewer. Standard access
tools do not generally work with special viewers at this time.
To Next Section - Appendix A (Summary of the recent changes to Mosaic)
To Table of Contents
Problem:
Back ground graphics, text colors and colorful images are being
used fairly frequently in the design of web pages. Although this
may make the page appear more attractive or memorable to some,
to others it is not readable.
Solution Strategies
10-1: Background patterns and color should contrast well with the lettering to maintain readability (background refers to both backgrounds of pages and backgrounds of images.
10-2: Select colors that will make your pages easy to read by people with color blindness. One good test is to see if your pages are readable in black and white.
Paul Fontaine, Paul Wilson, Peter Korn, Mike Paciello, Chuck Letourneau,
WGBH and Pat Powers for their input and contribution to these
guidelines.
To Next Section - Appendix B(Experimental solutions and discussions of d-tags, alt-text, text anchors, forms and edit boxes.)
To Table of Contents
In the previous sections we have presented approaches that can
be used to increase the accessibility of your HTML. There are
several approaches that we are testing and soliciting input on
that are not yet ready to be included in the guidelines. We include
our current thoughts on these experimental approaches to generate
discussion, ideas and solutions.
The following section is divided into 3 categories:
WGBH has pioneered the use of d-tags or "description tags"
in order to describe the graphic image to which the tag is linked.
These d-tag descriptions are longer and more descriptive that
the definition afforded by alt-text. As many persons who have
lost some or all of their vision wish to know more about the physical
dimensions of the page, this is a real plus. The questions and
comments below are designed to help develop a consistent policy
on the use of these tags. With such a policy, users with text
browsers and persons who use screen readers will be able to develop
the same knowledge of the site as persons who are using graphical
browsers. The well thought out use of d-tags will allow any user
who is not seeing the graphic image to obtain quality information
about the graphic or to simply proceed without it.
These questions and comments were generated by looking at worse
case scenarios. Often, the pages we used as models were image
maps which were totally unrecognizable by the screen readers we
used. The page containing these image maps also contained additional
links.
D-TAG FORMATS
PRESERVING THE FEEL OF THE SITE
TEXT VERSIONS OF A PAGE OR AN ENTIRE SITE
CONCLUSION
Because the use of d-tags in some of the scenarios we have presented
here would greatly change both the nature of the site and the
amount of work needed to maintain it, we need to have a better
feel for the numbers of persons who would desire these tags, and
how they could best meet the needs of different users.
Problem:
Screen readers will often read the alt-text of image anchors and/or text anchors as one link if there is no punctuation between them.
For example: a menu bar at the bottom of a page made up of one image anchor and two text anchors. The alt-text of the image and the first text anchor are read as one.
<A HREF="/pathname/link1.html"> <IMG SRC="/pathname/image.gif" "link1" ALT = "link1"></A> <A HREF ="/pathname/link2.html">"link2"</A> <A HREF ="path/link3.lhtml">"link3"</A>
Experimental solution:
a space and a vertical bar on either side of the text anchors resolve the problem. This will also separate the links for visual users. Some authors use two vertical bars instead of just one.Note: adding JUST a space or JUST a vertical bar is not enough to solve the problem ALL of the time. In some instances one or the other might work, but together the screen reader software we are using has consistently paused between links. Other punctuation may work, but we tested with vertical bars because we felt it not only increased the accessibility by a screen reader but it separated the text visually as well.
Example:
<A HREF="/pathname/link1.html"> <IMG SRC="/pathname/image.gif" "link1" ALT = "link1"></A> | <A HREF ="/pathname/link2.html">"link2"</A> | <A HREF ="path/link3.lhtml">"link3"</A> <P> <B>Note</B> that there is a space before and after each vertical bar.
Problem:
alt-text is sometimes centered vertically next to the image icon and thus read on a different line.
Example:
Would most likely be read:| <A HREF ="/pathname/link1.html">"link1"</A> | <A HREF="/pathname/link2.html"> <IMG SRC="/pathname/image.gif" "link2" ALT = "link2"></A> | <A HREF ="path/link3.lhtml">"link3"</A> <P>
link2, link1, link3
Experimental solution:
A possible strategy is to take the image out of the sentence and put it before or after the paragraph or sentence. Authors can turn images off and see the placement of the alt-text, but the words may wrap differently on different browsers depending on the width and text size that users have chosen.
Problem:
Sometimes when alt-text is included in a sentence it is hard to tell where the alt-text ends and the text of the paragraph that it is included in begins.
Experimental solutions:
Place a character before and after the alt-text string. For example an x. This will be read by all screen readers, but may make things MORE confusing. For example, if this were the alt-text of an image map, "x see links below x" the "x" could be confused with an entity. i.e. icon x, x distance of miles to go, etc. This also adds two syllables to each alt-text entry.Another alternative is a slash (/). This way a person using a screen reader could turn the correct level of punctuation on so that a slash will be read or turn it off if they do not wish to hear the begin and end of the alt-text. With some screen readers, no punctuation means NO punctuation and in order to hear the slash some punctuation needs to be turned on. However, this also means that point (.), comma (,), @, %, ^, &, \, # etc. will be read which can greatly increase the amount of time and energy it takes to read a page. Including punctuation sometimes confuses the context of a sentence. For instance, "With some screen readers point no punctuation mean no punctuation point"
Problem:
If height and width are specified for an image, the alt-text might wrap. If there are several images in a row all whose alt-text have wrapped a person with a screen reader might not be able to read this at all since a screen reader will read across the page. For instance if the alt-text were, "TRACE logo" "TRACE documents", "TRACE calendar." And depending on how the images were sized, a screen reader could read this as:TRACE TRACE TRACE
logo documents calendar.
This also may make the alt-text unreadable for sighted people.
Current solution:
At this time, a text-only version seems to be the only solution, unless the author can find a way around using the height and width attributes of images or use them in such a way that the text will not wrap. This is almost impossible to test however because people will have selected different fonts and sizes to be displayed by their browser.
Problem:
Screen readers pass over edit boxes which are empty. The user has no way of knowing they are there. Even if they know, for example, that there is likely to be an edit box for entering a search query, it is difficult to place the mouse pointer on the edit box without sighted assistance.
Experimental solutions:
Please send comments and suggestions to: web-team@trace.wisc.edu