On Universal Accessibility and Online Journals

Sandra Sutton Andrews
Ivana Batarelo
Samuel A DiGangi, Ph.D.
Angel Jannasch-Pennell, Ph.D.
Arizona State University

Contents

Part I: An Introduction

In the beginning:
The original purpose of the World Wide Web (as conceived of by its designer author, Tim Berners-Lee) was the free sharing of information across networks. The concept was this: within a network, users might access information in many different ways; might use any platform; or might simply print the information received. Regardless of device or program used, the information itself would be accessible. This was accomplished by marking up information according to standards, so that any device might be configured to display it.

[Next_computer]

[Berners-Lee created the Web on a NeXT machine such as this, in 1990.]

[Next_logo]

This emphasis on the marking up of information for ease of sharing was the key that led to the explosion of websites across the world. When the Web was largely text, anyone could access any page, including researchers in third world countries and visually impaired people listening to their computers read text aloud to them. However, imagination and innovation led to the use of animation, video and sound; this was accompanied by the development of high-bandwidth connections for some; developers never looked back, and the web began to be less open to many people.

For sound is not accessible to Deaf people.
Video is not accessible to blind people.
Animation is often not accessible to either.
All three (sound, video, animation) may be very high bandwidth and thus inaccessible to people in places (inner cities, rural areas, some other countries) where high-speed Internet access is rare.

Moreover, those who are mobility-impaired may not be able to use a mouse.
Learning disabled people may be distracted by moving design elements.
Colorblind people may be unable to read pages created with some color combinations.

Today, Tim Berners-Lee is still active in the evolution of the Web, for he directs the World Wide Web Consortium, or W3C, the standards-setting body that is located online at http://www.w3c.org . An ongoing priority for the W3C is universal access. As Berners-Lee has stated, "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect" (Berners-Lee, acc. 2001).

One division of the W3C is the Web Accessibility Initiative, or WAI, located at http://www.w3c.org/wai/.. Universal access is defined by the W3C as accessibility for all devices (computers, printers, cell phones, PDAs); accessibility for people with visual, hearing, physical and cognitive/neural disabilities; and accessibility regardless of level of connectivity. The WAI's Web Content Accessibility Guidelines (WCAG) cover all of the above and have become the standard by which other guidelines (Federal and State) are developed.

Early adopters of technology in the field of education used the phrase "information gap" to describe families who could afford a computer in the home in contrast to those who could not. It was Lloyd Morrisett who, sometime in the 1990's, coined the more colorful term of "digital divide" (personal communication, February 14, 2002). The term is generally applied to computer access plus Internet connectivity, and the divide exists in a variety of aspects: there is a socioeconomic divide; a racial divide; a divide between rural and urban parts of the United States; a divide among wealthy and poor nations; and there is a divide between those who have difficulties accessing print for physical reasons such as visual or motor impairments, and those who do not. The W3C addresses the entire digital divide: One of W3C's primary goals is to make the benefits of technology available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability (W3C, acc. 2002).

One aspect of the divide directly impacts educational researchers, since those without high bandwidth connections have less access to research that is presented via video and other high-bandwidth solutions. Gene Glass and John Willinsky have been instrumental in the movement to publish research freely on the Internet; but publishing electronically does not guarantee access to everyone (Glass, 1999; Willinsky, 2000). While we may not be able to distribute hardware and connectivity to the globe, we can at least code our electronic journals for ease of downloading.

Another aspect of the digital divide is access for the disabled. As Norman Coombs, founder of Equal Access to Software Information (EASI) explains, "The web is an amazing and miraculous thing for millions of the formerly print disabled. Using adaptive computer technology, these people can now read newspapers, search distant library databases, shop, chat and exchange e-mail. However, thoughtless web design can also slam the door of freedom and independence in their faces" (Coombs, acc. 2002). As educators we are thus faced with an unprecedented opportunity: by placing our research on accessible websites, we can expand our audience to include the entire research community as well as interested outsiders.

Part II. Methodology

Introduction

For this paper, we examined the more than one hundred online, peer reviewed journals gathered by T. Ganesh and by Gene Glass for the Communications in Research SIG and located at http://aera-cr.ed.asu.edu/links.html . We used JAWS and Lynx to identify the most common accessibility problems for the visually impaired; checked the HTML source code for each site; and visually examined pages for other problems. JAWS (Job Access With Speech) is the most sophisticated screen reader available; Lynx is a text-only browser that continues to be used and developed. JAWS is the best known screen reader for the visually impaired; it can read web pages as well as other files on the computer. Other solutions are WindowEyes and IBM's Home Page Reader. Lynx is useful for those who, like us, wish to test accessibility. If a web page is usable under Lynx, then it is very likely compatible with Home Page Reader, WindowEyes and with older versions of JAWS. The newest version of JAWS is more advanced than the current version of Lynx in some ways, but, as with browsers and video players, it cannot be assumed that all members of the audience will have the latest version; hence we code for older versions as well. We assume that you already realize that one of the best ways of finding problems is to review each web page in all current browsers and platforms. Adding Lynx, JAWS, and other screen readers to this list is the easiest means of gaining accessibility quickly.

The following section constitutes a simplified list of suggestions for those attempting to make their web pages accessible to all. The suggestions are based on the most common problems that we identified among the online educational journals. These problems have to do with all three types of access mentioned above: device independence; disability access; and connectivity. Time constraints dictated that we examine only the first page of most journals. To our surprise, we found no optimally accessible online journals in education.

Problems and Solutions

As webmaster or editor of an online journal, your goal is to transmit information quickly and professionally. This means that the reading or listening experience should be as seamless as possible. Journals that publish traditional (primarily text) papers make up the vast majority of those examined. While the journal sites themselves may be more complex, they still rely primarily on text and images. Thus we will focus first on means of making pages accessible to screen readers (for the visually impaired) and to text browsers (which have features similar to those of screen readers). However, we will also discuss accessibility in terms of the Deaf, the color-blind, the learning disabled, and the mobility impaired. For our examples we used screenshots of actual journals as they appear in Lynx, which may be thought of as a visual equivalent of a screen reader. However, the screenshots were modified so that the journals cannot be identified.

Many of you may have begun by writing the HTML code for your pages yourself, and it is still important that you or your web designers know how to do this. Programs such as Dreamweaver (the industry standard) now do a reasonably good job of creating the HTML; designers need only push and pull graphics and other elements around the page, and the HTML is automatically created. While Dreamweaver can be configured for better accessibility, if there are problems with the code, you will still be better served if you can fix the HTML yourself.

Let's begin at the beginning by looking at the source code.

  1. While a DOCTYPE statement is not a matter of accessibility as yet, some validators will not accept pages without such a statement. (In the future the DOCTYPE statement may become very important for accessibility, as will be discussed later.) The DOCTYPE statement is placed at the very beginning of the HTML code. Here is an example that suggests your pages are compliant with HTML 4, and that your language is English:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    Validation programs are programs that check your code and tell you whether or not your HTML code is valid, or (depending on the validator) whether or not your pages are accessible to the disabled. We will discuss the most important validators at the end of this section, but it is important to realize that no validator can ever tell you whether or not your pages are truly accessible. Many decisions must be made by you or your web designer. For example, no computer program can tell you whether or not the alternative text presented for an image is appropriate, for a computer program cannot determine the difference between a nonsensical phrase and one that sparkles with genius.

  2. Make sure that the name of your journal, and any other important information, are immediately viewable, both in the "title" element and on the page itself. First, include the journal name in the "title" element. Here is how to do this: your HTML document is divided into two parts, the "head" and the "body." Within the "head" is the "title." This title appears in the bar above your web page. On the main page, the title will be the name of your journal. On secondary pages, you would do well to use an abbreviated title plus the function of the page: for instance, you could use JRR-Archives for the title of the Archives page of the Journal of Rest and Relaxation.

    So far we have:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
    <html lang="en-us" >
    <head>
    <title>
    Journal of Rest and Relaxation
    </title>
    </head>

    A header with the journal name is usually placed at the top of the first page. If your header is a graphic, the information it carries will be invisible to some users. Use text rather than such images that replace text if possible. Or, provide alternative or "alt" text for the graphic. For example, if "banner.gif" is actually an image that says "Journal of Rest and Relaxation" then users of older screen readers will only hear "banner.gif." The users of even older screen readers will only hear the word "image." (The newest version of JAWS will simply skip over any image that is not identified with alternative text; the reading experience is thus streamlined, but now the visually impaired reader will not even realize that information is missing!)

    Now we have:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
    <html>
    <head>
    <title>
    Journal of Rest and Relaxation
    </title>
    </head>
    <body>
    <img src="banner.gif" alt=Journal of Rest and Relaxation>

    With this "alt" text in place, the user of a screen reader will hear, and the user of a text browser will see, exactly with same thing that the viewer of the full color image sees.

    Since we are merely substituting text for a text graphic, we do not want to set the text off in any way. Quotation marks are often placed around alternative text; Lynx will not show quotation marks, as, strictly speaking, they are a part of the markup. JAWS, however, will read quotation marks aloud, while ignoring single quotes.

    Without the alternative text, the text browser displays this:
    [banner.gif]

    With the alternative text, the text browser displays this:
    Journal of Rest and Relaxation

  3. Use alternative text whenever you use images, imagemaps, or other features that will not be clear to the visually impaired reader. The use of alternative text is the single most important feature for accessibility, so don't stop with the journal name.

    1. If you use purely decorative images, or invisible images as spacers, use "empty" alternative text.
      <img src="spacer.gif" alt=" ">

      With the use of empty alternative text, even older screen readers will simply skip over the image, streamlining the user experience.
      Here is an actual example of what the text browser shows (and the users of many screen readers hear) if empty alt text is not used. Imagine how frustrating it would be to hear "spacer" or "image" over and over.

      2. [Lynx_screen_use_of_spacers]

    2. If you use any sort of image that conveys information, convey that information in the alternative text.

      1. Whenever you have an image with text, provide that text as "alt" text as well. For instance, if you have a graphic containing this Buckminister Fuller quote, please present it in this way:
        <img src="buckminster_fuller_quote.jpg" alt="The world is now too dangerous for anything less than Utopia. Buckminster Fuller.">

      2. If you have a photograph or other image, describe it clearly and briefly. Note: it is a convention to place in square brackets any longer alternative text that represents something other than a text graphic. Unlike quotation marks, the square brackets will be read aloud.
        <img src="edbuilding.jpg" alt=[photo of education building]>

      3. If such a description is long and there is no way to shorten it, place a letter "d" (for description) after the image and link this single letter to a page with a longer description. This way the viewer can choose whether or not to hear the description. You may want to set the font of this letter to the same color as the background so that sighted users are not distracted. As an example, consider a portrait of the dean of your college; let us say that the portrait is displayed on a page with a blue background color. We could write:
        <img src="dean.jpg"> <a href="description.html"> <font color="blue"> d </font> </a>

        In this case the letter d is linked to a page called description.html.The text on this page can then go into great detail about the dean and about the significance of the photo. A feature planned for browsers of the future is the "longdesc" element; but this has not yet been implemented by browsers.

  4. Alternative text is also important for imagemaps. Many journals use imagemaps for navigation, and some use a single large imagemap on the first page of the journal. In either case, it is important to provide good alternative text both for the map as a whole, and for each area. The alternative text for the map as a whole might be "menu" or "navigation." Each area would then contain alternative text giving more information about the link attached to it: "This Issue" or "Archive" or "About the Editors." Here is a good example:

    <img height="300" width="300" src="images/navbar.gif" border="0" usemap="#mainMap" alt="Navigation Map">
    <map name="mainMap">
    <area coords="5,244,125,273" shape="rect" href="contact/index.html" alt="Contact us">
    <area coords="6,206,122,234" shape="rect" href="curr/index.html" alt="This Issue">
    <area coords="5,166,156,195" shape="rect" href="res/index.html" alt="Resources">
    </map>

    Without alternative text for the map as a whole, the imagemap will be identified by its underlying graphic, formatted as a link. If the name of the image is "imagemap.gif," then the user of a screen reader will hear the not particularly useful phrase:

    [USEMAP:imagemap.gif]

    If your user then clicks on the imagemap link, and the various areas of the imagemap are not given alternative text, a list of links (with no explanation of where the links lead) will appear. The user will have to take a wild guess as to which one might be important. Note: the latest version of JAWS, while programmed to skip graphics with no alternative text, will read the name aloud if the graphic is a link. However, alternative text is still important to give the user an idea of the nature of the link. For instance, let us imagine a bilingual journal. In this example, the journal editors have created two versions of their journal, but users will not intuitively know this since no alternative text has been given, and the names of the links do not provide a hint.

    5. [Lynx_screen_]

    [Lynx_screen_]

  5. Many sites use JavaScript, Java, or other programming means to enhance a website. If you are merely creating fancy rollover buttons, there is no functional harm done if some people cannot appreciate the esthetics. However, it is important to offer any information given via such scripts in an accessible way as well. Scripts that open new windows or provide drop-down lists of options may or may not work, depending on the way the script is written. You can provide the same information with an invisiblelink in which the font color is the same color as the background. Note that this is considered a last resort solution, as the webperson then must update two pages instead of one.

  6. Frames were an early vision of a means by which information could be repeated from one page of a website to another. Users of older screen readers will have problems with frames, so avoid them if you can. New screen readers can handle frames with less difficulty, although the user experience is still not smooth. If you do use frames, it is important to include title and name attributes on each frame link on the "frameset" page, as well as a "title" on each frame page. Otherwise, as with imagemaps, your user will be presented with a list of links that may make little sense. If the frameset page gives no titles/names, here is what the users of some screen readers would hear. One would have expected the main frame to hold the content, and the left frame to hold the navigation, but even these conventions were not followed.

    [Lynx_screen_frames]

    To fix this, try the following:
    A frames site is created with several HTML pages. The first is the frameset document, which lists all of the frames. Next to each frame, provide a title and a name (some screen readers use the title, and others use the name attribute.) Don't forget to include a title on each HTML page, as was explained in point two, above.

    <html>
    <head>
    <title>Sample Journal</title>
    </head>

    <frameset rows="150,*" cols="*" >
    <frame name="Fancy Journal Banner" title="Fancy Journal Banner" src="top_banner.html" >
    <frame name="Navigation" title= Navigation src="left_nav.html" >
    <frame name="Content" title= Content src=" main.html">
    </frameset>
    <noframes> <body bgcolor="#FFFFFF">

    Here you can place a link to a page for those whose browsers/readers do not support frames at all.

    </body> </noframes>
    </html>

  7. Similar advice holds for tables, which are used by most websites to format content by placing information into columns. Tables were originally intended by the W3C to be used for data, and standards for them were included with HTML 2.0. As soon as tables became possible, graphic designers seized upon them for purposes of layout, and arguments ensued with those who felt that tables should be used solely for data display. While some of the formatting generally provided by tables can now be handled via stylesheets (as will be discussed later), tables are currently so ubiquitous that it would be difficult to avoid their use. However, nested tables (tables within tables) should be avoided. This is because a screen reader can obviously only read one table cell at a time; if the screen reader reaches a table nested within a cell, it will thereupon progress through the entire nested secondary table before progressing to the next cell. In addition, nested tables can slow down loading for people with very slow connections. Modern screen readers have a great deal of support for tables, but not all viewers will have the latest software. Here are some tips if you feel that you must use tables:

    1. Use <p> and </p> tags to begin and end each paragraph in a column, or use other structural markup (such as markup for unordered lists) for all text in the column. This will allow the screen reader to treat as a unit the text that is marked up as one. Otherwise, some screen readers will read the first line in the first column, then the first line in the second column, then the second line in the first column, and so on. Here is a correct example:

      <table>
      <tr>
      <td> <p> Here is the first column.</p>
      <p>And here is the second paragraph in the first column.</p>
      </td>
      <td>
      <p> Here is the second column.</p>
      <p> And here is the second paragraph in the second column.</p>
      </td>
      <tr>
      </table>

      The above will look like this on the web page (depending on what widths, etc. you set for your columns):

      Here is the first column.

      And here is the second paragraph in the first column.

      		Here is the second column.

      And here is the second paragraph in the second column.

    2. Data tables are an important topic for research. For older versions of screen readers, data tables can be very difficult to mark up. The best advice we can give you is to suggest that you make sure that the logical structure of your table is airtight. Otherwise, information that logically is on the same level may not be presented as such. For data tables:

      1. Give a summary of the purpose of the table, so that users can decide whether or not to continue. This summary will be read aloud but will not appear on the page.

      2. Use a caption for the table. This will be read aloud and will appear on the page.

      3. Use HTML markup for table headers. The use of header information will cause the screen reader to present information that belongs together, together. If headers are long you can assign an abbreviation that will be read aloud.

        Here is an example of a captioned table, followed by the HTML with summary attribute and with headers identified for screen readers.

        Accessibility and Online Journals
        Name of Journal Use of Alt Text Use of Animation
        Journal One Yes No
        Journal One No Yes

        <table border="0" summary="Table showing accessibility features of online journals. Results: no journals were completely accessible.">
        <caption>Accessibility and Online Journals</caption>
        <tr>
        <th id="t1">Name of Journal</th>
        <th id="t2" abbr= alt textî>Use of Alt Text</th>
        <th id="t3" abbr= animationî>Use of Animation</th>
        </tr>
        <tr>
        <td headers="t1">Journal One</td>
        <td headers="t2">Yes</td>
        <td headers="t3î>No</td>
        </tr>
        <tr>
        <td headers="t1">Journal One</td>
        <td headers="t2î>No</td>
        <td headers="t3î>Yes</td>
        </tr>
        </table>

  8. Languages: screen readers do a good job of pronunciation, but if you have set your page to English, and then you include a French expression, the French will be mangled and incomprehensible. Announce the fact when you change languages with the lang attribute. If you use a DOCTYPE statement then you have already told all devices that you are beginning with English. The Library of Congress has an online list of language codes at http://lcweb.loc.gov/standards/iso639-2/langcodes.html . Here is how to switch to another language:

    <P lang="de">Alle Menschen werden Brüder, wo dein sanfter Flügel weiht."

    <P lang="hr">O lijepa, o draga, o slatka slobodo.

    <P lang="en"> O beautiful, o dear, o sweet freedom.

We have discussed, thus far, identified accessibility problems for journal websites and for text articles. More complex articles, with video and the like, require more work. Researchers with slower connections may lack the newest version of browsers. If they use a shared connection they may not personally have control over what software is available. There may be no one who can install the latest version of a video player or browser. Here are some guidelines:

  1. If an article contains video, use built-in features of video editing software to create optional captions, for the Deaf, and synchronized descriptions, for the visually impaired. A transcript should also be offered.

    Video editing software can automatically create several versions for different connection speeds and serve up the proper one automatically. The final step is to offer separate versions for older video players.

  2. If an article contains audio, present a text version describing the content; in the case of spoken words, give a transcript. Again, you can create different versions for fast and slow connections.

  3. In the case of animation, consider moving from Flash to SVG. Flash, while wildly popular, is hardly accessible. While the newest version of Flash offers some accessibility options, these have been criticized as not being well thought out. Flash is low bandwidth and can be viewed even by people with a slow connection, but the only way to truly make the information carried by it accessible to visually impaired users (and in many cases to Deaf users) is by creating a second, alternate version of the information. Future versions of Flash may, of course, be capable of far more. SVG, or Scalable Vector Graphics, is a newer format based on XML. SVG animation will thus allow you to create an alternate text version parallel to the animation itself.

Other Disabilities and Solutions

Thus far we have discussed access for the visually impaired (the most complex issue), for researchers with slow connections, and have touched on access for the Deaf. Let us briefly look at some other accessibility problems that are important to address.

First, access for the Deaf is a complex issue. Sign is a language of its own. Further, as it is based on concepts expressed visually rather than on words, sign is very different from written English or from other written languages. In effect, to the Deaf, written English is a dead language, difficult to follow for one who is not fluent in spoken English and difficult to translate into sign (Batson, 1996). For those who wish to address a Deaf audience, the recommendation is to use many images, to use as few words as possible, and to "chunk" information. In the case of academic papers, an alternate version for the Deaf is not generally expected, but we provide this information in case researchers wish to address a Deaf audience for a particular reason.

Learning disabilities can be exacerbated by distracting elements. The most important one for us is repeating animations, which should be avoided (along with scrolling Javascript text along the bottom of the page). Animations can also affect those with some cognitive disorders.

Colorblindness is an issue for a surprisingly large number of people. To avoid problems, provide sufficient contrast between text and ground: avoid using red and green next to each other, or grey/blue/purple. Also, make certain that no information is dependent solely on color for understanding.

People with low vision are frustrated by font sizes that are too small. Since browsers do include a means of increasing font size easily, this aspect no longer causes major difficulties. However, font sizes should be checked in both Netscape and Internet Explorer, and on Unix, Windows and Macintosh machines, to make sure that text is legible.

Finally, remember that some users do not use a mouse but must use a mouthstick, voice commands, or other device. We did not find any examples in our review of the journals, but on occasion animations do require the use of a mouse, so this caveat is worth remembering for the future.

Into the Future

Two other aspects of modern web design are worth discussing briefly. The first is Cascading Style Sheets; the second is XML. Both hold promise for accessibility.

Cascading style sheets are the newer means of formatting web pages, and some HTML editors create them automatically. The purpose of CSS is to help separate formatting from content and structure. This relates to accessibility, since it would be relatively easy to create a stylesheet especially for text browsers, for example, and a more complex one for regular browsers; the content would remain the same and could be updated once for each stylesheet. In one sense, CSS fulfills the original purpose of frames, in that information can be input once for all pages of a website. Formatting goes into the style sheet; content goes in the HTML. CSS is already the standard, and HTML formatting tags such as <font> may at some point no longer be supported by browsers. CSS has two problems that have slowed its adoption: 1) in comparison to HTML, it is difficult to write (although it is not as difficult as it looks) and 2) it is unevenly supported by browsers. While newer versions of the main browsers do support CSS, they do not always interpret CSS in the same way, and older versions of browsers do not support it at all. Newer screen readers have no problem with CSS, and the use of CSS files can speed loading. Because CSS is the standard, we suggest that you begin using it for some formatting, in ways that "degrade gracefully" or that, in other words, allow your journal to look respectable even if seen with an older browser. If you wish to go further with CSS, you will want to learn more and/or to hire a technical person who knows how to ensure that your pages look good on all browsers and platforms.

There are two ways to use stylesheets: you can "embed" the stylesheet information into a web page, or place it in external stylesheet that can then be referenced by all of the pages of a site, should you wish. For beginners, embedded stylesheets are perhaps a little easier. We suggest that you use stylesheet information to format the fonts of your pages, as follows. Choose your own fonts; but the inclusion of as many elements as possible will insure that the font remains the same in each, and in every browser.

<HTML>
<HEAD>
<STYLE>
a{text-decoration:none}
body, caption, div, h1, h2, h3, h4, h5, h6, p, th, td, dl, dt, dd, ol, ul, li, input {
font-family: Verdana, Arial, Helvetica, sans-serif;
}
</STYLE>
<TITLE> Current Issues in Education </TITLE>
>/HEAD>

XML, or Extensible Markup Language, is another technology that is on the horizon. XML will allow us to create templates for more than one sort of page: for instance, a graphical site; a site optimized for screen readers; and a site optimized for viewing on a Blackberry. XML, then, can have a tremendous impact on accessibility and in fact will revolutionize the creation of accessible websites. For now, you can at least add a DOCTYPE statement to your websites, as it is projected that XML pages will use this statement to identify the particular template that will be sent to the different devices. (The use of XML may require that you hire someone with a background in programming, but this will be worth it.)

Validators were mentioned early in this paper. Two important validators are the W3C validator, which checks your code; and the Bobby validator, which checks for accessibility. Both offer an icon that you can place on your pages to show that you are in conformance with standards. As mentioned earlier, however, while conformance to HTML standards can be checked by means of a computer program, the decisions made towards maximum accessibility cannot be easily checked. Two other websites offer alternative icons that can be used by those who wish to state in good faith that they are aiming at accessibility. One is the WGBH (Boston's PBS station) website; the other is Arizona State University's Education Accessible website. The former was instrumental in pushing for accessible alternatives to multimedia. The latter offers a tutorial on the WCAG, plus a simplified/translated version of these guidelines.

We will conclude this discussion with an older feature of HTML that is supported by many of the journals reviewed for this paper, meta tags. As with the DOCTYPE statement, meta tags will add to accessibility at some time in the future when the use of XML is common. At that point we will probably be using meta tags created especially for education. In the meantime, since meta tags do make a site more searchable, we can add two commonly used meta tags to our pages, "keywords" and "description." The various search engines may make use of one of these for their descriptions of a site. You may want to include the term "education accessible" in your list of keyword phrases. Here is an example:

<META Name="description" Content="Current Issues in Education, a peer-reviewed scholarly electronic journal">
<META Name="keywords" Content="current issues in education, educational research, educational journal, online education journal, education, educational policy, vouchers, charter schools, evaluation, educational evaluation, education reform, school reform, educational reform, accountability, school choice, standards, higher education, academic standards, testing, assessment, teaching, journal, private schools, teacher unions, educational assessment, education quality, education accessible">

PART THREE: Tables showing accessibility problems of online educational journals.

Accessibility and Online Journals
Feature Percentage
Have some Alt text 43%
Are missing alt text from navigation buttons 83%
Lower Bandwidth or text only version of journal exists 3%
Use CSS for formatting 16%
Have Doctype statement 33%
Use of meta tags (keywords & description) 42%
Obvious use of an editor 26%
Have an animation 2%
Use Image maps 17%
Of these, image maps that are not marked properly 52%
Have frames 13%
Of these, have bad frames 64%
Java Script 16%
PDF 6%
Accessible with Jaws 5 74%