Accessible HTML eBooks

From DPWiki
Jump to navigation Jump to search

This large document uses the W3C's Web Content Accessibility Guidelines as a framework for discussion of how we can create more accessible eBooks. For more detailed and specific help on various features, try the new Accessibility Recipes.

Introduction

Project Gutenberg ought to be a flagship of accessibility. Often people ask why we do all this proofreading, when surely we could preserve far more books if we just put up page images. Accessibility is one of the best answers. Even a simple plain text file is more accessible than an image, and a little bit of care can ensure even broader accessibility. Simple adjustments in postprocessing could make a world of difference to people who are color-blind, who use screen readers to read our eBooks, are unable to use a mouse, etc.

There are a lot of useful guidelines for accessibility on the web, including the W3C Accessibility Guidelines, some of which are referenced here. But remember that we are dealing with a special case, and that eBooks are different in some ways than web pages, which are the focus of much of the online advice available. For example, sometimes these sites recommend changing the text of a page to support accessibility, which is not an option for us. And while web page guidelines often recommend the latest technology, we need to create texts that may be unchanged for decades and support the widest possible array of reading devices.

In the sections below, where applicable, a box shows the Priority of each item according to version 1.0 of the W3C's Web Content Accessibility Guidelines: a red 1 for mandatory items, an orange 2 for recommended items, and a green 3 for optional items, followed by the rule number from the original WCAG.

General Principles

When creating accessible etexts of public domain sources, there are a few basic principles we must follow:

  • Consider accessibility from the beginning. Don't add accessibility as an afterthought; ask yourself at every stage if a decision will affect accessibility. This is especially important if your project relies on technologies that can break accessibility: MathML, LaTeX, table column alignment, etc.
  • Don't change the original text. The goal of Project Gutenberg and Distributed Proofreaders is to preserve texts, not to improve them. This means we can't follow certain accessibility advice, such as "front-loading" (re-drafting a paragraph with the conclusion first so that people using a screen reader can choose to skip it). Also, since we're not the original authors, it's not always obvious whether to tag italics in a text as <i> or <em>--we can expect careful editing from our volunteers but not mind reading.
  • Follow PG guidelines. Similarly, PG guidelines make some web accessibility advice impractical. For example: every PG text must include all CSS and HTML in a single file, making recommendations for separate "longdesc" file links impractical.
  • Add new content sparingly and thoughtfully. Accessibility sometimes requires adding new content like alt tags and table summaries. Keep this new content objective and avoid editorializing.
  • Document your work. If you do add original content, say so in your Transcriber's Notes and clearly state that you are placing any original content in the public domain.
  • Think about compatibility. Not all browsers support all modern HTML or CSS formats. Don't add accessibility features that break the text for existing users on older browsers, and only use well established features--our ebooks are going to be around for decades, long after the latest proposed standards may have changed or disappeared.
  • Don't Cut Corners. If you're thinking of solving a visual problem with a creative use of an HTML element like a table, list, or header, don't. Find a solution that follows good HTML practice and document semantics. Many issues arise when people use HTML elements to change how a text looks, without thinking about their semantic meaning.

Specific Elements and Items

One of the most important things you can do to support accessibility is to follow the existing Project Gutenberg and Distributed Proofreaders guidelines. Use valid markup and CSS and avoid things like scripting and frames, which can break accessibility. Remember that while we use CSS to style our books, all DP html files should be fully legible without any CSS. Following this rule will also help with accessibility in most cases.

Some items, like images and tables, also require specific special treatment to be accessible to everyone. The list below covers some items where you just need to follow the rules, and some where you need to take extra steps.

Abbreviations

Semantically tagging abbreviations with the <abbr> tag helps screen readers properly identify and pronounce abbreviations, initialisms, and other shortened versions of words. It is good practice to mark up abbreviations in your text with the <abbr> tag.

Abbreviation Titles

The "title" element in an <abbr> tag is used to give the full version of an abbreviation or acronym. This can be useful in some cases, but is not recommended for every abbreviation in a text. It is only necessary to add a title element to the first occurrence of an abbreviation; the

If your text mentions an acronym with a commonly understood meaning, like "laser," or "UK," or "Mrs.", it should be marked with an <abbr> tag but adding a "title" element is not necessary; it just creates audio or visual clutter.

If there is an acronym that was once well understood but is not likely to be familiar to a modern reader, you may consider adding a title element. In a visual browser, this will normally show as a dotted line, allowing the reader to hover over the text to see the expanded version. Screen readers may also make this available to the end user, although support is not universal.

For example, the Aerated Bread Company was a popular chain of teashops in London in the late 19th and early 20th centuries, and their locations were commonly called "A.B.C. stores." The phrase here was coded as: 

<abbr title="Aerated Bread Company">A.B.C.</abbr> stores.

In a visual browser, hovering over the "A.B.C." in the paragraph above should show you the expanded version.

Even where an abbreviation is spelled out in the text on its first usage, the <abbr> tag may help some readers; because navigation is easier in an ebook, readers are more likely to skip to the section of a book that is relevant to them. This is especially true of those using screen readers, as it's not possible to "skim" in the same way a visual reader would.

Types of Abbreviations

There are multiple types of abbreviations, including acronyms like "laser" which are pronounced as a word, and initialisms like "E.U." in which each letter is pronounced separately.

In previous versions of HTML there were a separate <abbr> and <acronym> tags. However, <acronym> has now been deprecated and it is now recommended to use <abbr> for all abbreviations.

An alternate way of showing which type of abbreviation is to use a standard vocabulary like the Structural Semantics Vocabulary. This uses the epub:type attribute to identify an <abbr> as either "z3998:acronym", "z3998:initialism", or "z3998:truncation". While this is a standard it may not be universally supported and is not required.

Color

Accessibility for users with a color vision deficiency (colorblindness) is important in general web design, but less so for our work at DP, because most of our output is plain text, and where color images do exist they are generally pre-existing images that we can't change. However, there are a few areas where you may run into issues:

  • Cover images
  • Transcriber's notes
  • Links

General Principles

The best way to accommodate colorblind people is to:

  • make sure no information is conveyed only through color, and
  • use contrast as well as color.

Cover Images

When creating new cover images for ebooks, ensure that there is enough contrast between the background and any text that the text is easily visible, even if you change the image to grayscale. Consider using a high contrast block for the title text (e.g., black text on a white rectangle) rather than placing the text directly on a colored background.

Transcriber's Notes

The other place color sometimes appears in our ebooks is in the Transcriber's Note. It is okay to use a light colored background to set off your transcriber's notes, but remember that a colored background may be less visible to a person with a color vision deficiency. Consider also using a border, changing to a sans serif font, or setting the transcriber's note off from the rest of the book in another way as well.

Links

Avoid changing the default colors of links, or removing underlines from links through CSS. A user with a color vision deficiency may rely on a customized browser or ereader to identify links and distinguish between followed and unfollowed. Too much tinkering with CSS can cause problems for these users.

Other Issues

  • Do we mind if people can't see our visible pagenums, in the interests of making them unobtrusive for those with good vision?

Emphasis

  • The recommendation here is to use <em> and <strong> instead of <i> and <b>. Or, where these occur in section headings or around foreign words or whatever, to mark up those semantically and style them using CSS.
    • One could argue that we are trying to represent a visual medium, namely a dead-tree book, and that we don't know what the author's italics meant.
    • Or that moving the italics and bold to the CSS is bad for non-CSS users.
    • Speech browsers use a different voice inflection for emphasised and strong text. (Perhaps not for italic and bold?)
    • Using <em> and <strong>, if they are styled in the CSS to be italic and bold, can't hurt.
  • Other forms of emphasis can be achieved using CSS to style the tags differently. For example, "strong" underlining:
strong.u { text-decoration:underline; font-weight:normal; }
  • Don't fake gesperrt text by sticking in &nbsp;s, as this will cause screen readers to spell out the word letter by letter. Try this CSS instead:
em.gesperrt { letter-spacing:0.3em; font-style:normal; }

Headings

HTML headings should not be used for anything except structural headings. If you follow the guidelines in the Post-Processing FAQ and the Headings section of the Easy Epubs documentation, it will produce better ePub conversion and more accessible output.

Users who can't visually browse through a text rely on headings to navigate through it. Screen readers will read and list these headings for them. DO make sure to use heading tags for every heading, rather than just representing it with font size changes, and DON'T use headings for anything else. Don't, for example, use heading tags to represent the various sizes of text on a title page.

Images

Text equivalents should be provided for every non-text element. 1: 1.1

  • "Equivalent" means it should serve the same purpose as the image, rather than describing it. If you were reading over the phone, what would you say?
  • Ideally use normal prose, and include punctuation because this gives voice pauses. Beware of homonyms—i or eye?
  • Attributes are allowed to contain entities, so there is no need to strip accents from letters etc.

Alt text

  • Although every image must have an alt, it can (and often should) be empty, i.e., alt="". Assistive devices may present the alt text, so, as with improper headings and lists, we don't want to waste the user's time with unnecessary information. Some examples of where an empty alt is appropriate:
    • Spacer images. Add data-role="presentation" to indicate that the absence of alt-text is intentional.
    • Images whose caption is sufficient.
      • Don't re-use the caption in the alt: nobody wants to hear it twice. (Unfortunately old versions of Guiguts used to encourage this bad habit.)
      • Many captions comment on the image and don't describe it. In this case, alt-text is needed.
    • Images where an adequate description is in the body text, adjacent to the image.
    • Purely decorative images.
      • All accessibility guidelines are in agreement on this.
      • Add data-role="presentation" to indicate that the absence of alt-text is intentional.
      • However, this is an unusual situation. You may feel that despite being decorative rather than conveying information, an image is an essential aspect of the book we are preserving and so a description is warranted—are readers interested in the content of the book, or in the book itself and how the original looked?
    • "Eye-candy" images.
  • In many cases alt text is important for accessibility. In determining if this is so, consider the purpose of the image. For example an image may advance the narrative. Try to find a few words that accomplish the same thing.
  • "First, do no harm." Using something like alt="[image]" or alt="figure 2" is always worse than alt="".

Where alt text is appropriate, bear in mind:

  • Keep the alt text short and to the point, so that someone using a screen reader isn't subjected to unnecessary information. It is best to stay under 150 characters if possible. But, if the the image conveys important information, use enough text to convey that information.
  • Assistive devices usually indicate to the reader that the alt text is associated with an image, so it's not necessary to say that.
  • Use the words, language and spelling of the text for the alt text.
  • Special situations:
    • Images that are links.
      • The alt needs to say where the link goes.
      • Generally don't say "Link to...."; the browser tells the user that.
      • For us it usually only links to a larger image. Perhaps alt="The book's cover, linked to larger image." is ok?
    • Decorative horizontal rules.
      • Use: alt="" data-role="presentation".
      • Another approach is to use a real <hr> and use CSS to make the image show instead (but see note below about background images). [1]
      • Don't insert gratuitous <hr> elements. Many assistive technologies announce them.
    • Sliced images.
      • Put the alt only in one slice (no repeating, no "sharing out") and empty alt in the others.
      • If the image is linked, make it just one hyperlink around the whole lot.

Longer descriptions

  • Sometimes an image really is conveying important content that isn't already in the body text and can't be adequately replaced by a short alt text. A long description is needed.
  • This is traditionally placed in a separate HTML file. Perhaps PG will allow us to put them at the end of the file, if not in a separate file?
  • There are three methods of doing this:
    • A (normal, visible) hyperlink, that says "Description of image".
    • D-link: supposed to be a discreet hyperlink (showing just the letter D) to the description. Its use is disputed, and many prefer a normal hyperlink.
  • WebAIM has examples.

Images of Text

Avoid this, as the image will be useless to those who can't see it. 2: 3.1

  • Text that flows around images, or has a fancy image border, can be done without resorting to an image of the text: ask for help in the forums or browse the PP_examples_on_PG#Illustrations.

But if you can't help it (such as a complicated equation or lyrics in music notation), try one of the following:

  • Use good alt text (LaTeX code for an equation?).
    • But be aware that if the image is small and you specify its height and width (which is usually good practice), then the alt may be truncated on the screen.
    • What if you need to explain the notation you will use in the alt? See JKorpela's advice.
  • Reproduce the text below the image. (You may want to add a Transcriber's Note explaining that you've done this.)
  • Link to a much bigger, high-contrast version.
  • If the image plays the role of, say, a level-3 heading, you should still enclose it in <h3> tags.

Other Image issues

  • Background images are ignored by non-visual media (and often by browser settings or for print as well) so don't rely them for important content.
    • This affects some methods of handling decorative drop-caps, horizontal rules, and title pages with borders.
    • Linking to the image separately, and providing its text equivalent in the title attribute, helps somewhat.
    • Various methods of providing text in the event of no background images are known as Image Replacement.
  • Symbols also need a text equivalent.
    • For example, does a screen reader recognize the "Planet Neptune" symbol ♆? Using the title attribute will help sighted readers also.
    • The vast majority of symbols can be expressed using Unicode. Avoid using an image if you can use Unicode.

Language

Screen readers need to know the language in order to pronounce the words correctly.

  • Identify the document's base language. 3: 4.3
    • Just stick lang="en" (or fr or whatever) into your <html> tag. If you're using XHTML rather than HTML, use both lang="en" and xml:lang="en"
    • Problem with the above: PG's boilerplate is always in English. Alternative: wrap the entire text in one big <div> containing nothing but a language tag. The boilerplate will automatically go outside this <div>.
  • Changes in language. 1: 4.1
    • Just put the lang (and xml:lang in XHTML) onto any other tag that surrounds the passage, sentence or word that's in a different language, such as a <blockquote>, <q> or <span>. See this example.

Links and Navigation

  • Clearly identify the target of each link. 2: 13.1 Many browsers and most assistive technologies allow users to call up a list of page links, so descriptive links are a must.
    • By putting the link around a suggestive bit of text.
    • And/or using the title attribute. (Currently, screenreader users and sighted mouse users can access this text, but sighted keyboard-only users cannot.)
    • Someone may have tabbed to the link, and not heard what went before it.
    • Sighted or not, non-mouse-users hate the phrase "click here," as do people who skim web pages for the information they want.
  • Make sure links that look/sound the same all go to the same place. 2: 13.4
    • Again, assistive technologies may read the list of all links on a page.
    • Should we really have [2] linking to a footnote, and another [2] to return?
  • Avoid immediately adjacent links. 3: 10.5
    • Recall that this guideline was written in 1999; user agents have improved.
  • Allow skipping over things that a user may not want to listen through.
    • Such as ASCII art ... or the PG boilerplate? ;-)
    • Tables of Contents are very tedious: on many sites you see "skip navigation"; this is our equivalent
    • An Alphabetic Jump Table for the Index is a good idea
  • Make it easy to move around the document.
    • Discreet links back to the ToC?
  • Provide logical tab order for links, and access keys for important ones. 3: 9.4, 9.5
    • Tab order is probably ok, unless your book is unusual.
    • Try an accesskey for the ToC? 
      <a href="#toc" accesskey="3" title="Back to contents">ToC</a>
Unfortunately there are no true standard accesskey assignments. The RNIB recommends only numbers for accesskeys.
  • Anyone understand what rel and rev do? Contents is a valid link type. <a href="#toc" rel="Contents"> maybe? [2]
  • Consider making it more obvious which link has keyboard focus, so that you can see the cursor when tabbing through
    • Default is usually like this
    • This is achieved by a:focus, a:active { outline:yellow solid 2px; background-color:yellow; }. (Outline rather than border, because borders take up space and we don't want the text to reflow while tabbing from link to link.)

Lists

DON'T use list markup merely to get indentation or spacing effects. A screen reader will give the number of items in the list before reading the items, which will be confusing if it's anything but a semantic list. The definition list (<dl>) seems to tempt this the most.

DO mark up anything that is semantically a list as an HTML list, so that a screen reader will recognize it as such.

    • Don't instead use a bunch of <p>s and <br />s, or fake numbering/bulleting by typing in the characters.
    • The CSS display:inline property can be used for lists that look like this:
ul.inline li { display:inline; list-style-type:none; }
Introduction; Process of repair; Healing by primary union; Granulation tissue; Cicatricial tissue; Modifications of process of repair; Repair in individual tissues. 
 <<ul class="inline">
 <li>Introduction;</li>
 <li>Process of repair;</li>
 <li>Healing by primary union;</li>
 <li>Granulation tissue;</li>
 <li>Cicatricial tissue;</li>
 <li>Modifications of process of repair;</li>
 <li>Repair in individual tissues.</li>
 </ul>

Metadata

Fill in the metadata on author etc. 2: 13.2

There seems to be a belief that always filling in author, description and keywords is A Good Thing. I'm not sure how far it applies to our ebooks. Most sites suggest it's about indexing by search engines [3].

I (Jeroen Hellingman) typically include Dublin Core meta data in meta tags. 

 <link rel="schema.DC" href="http://dublincore.org/documents/1998/09/dces/">
 <meta name="author" content="...">
 <meta name="DC.Creator" content="...">
 <meta name="DC.Title" content="...">
 <meta name="DC.Date" content="...">
 <meta name="DC.Language" content="...">

The author and creator fields should contain the full name of the book's author, the title contains the title of the book, the date should be the date you upload the file, and the language should be the same two- or three-letter code you used in the lang attribute (e.g. en for English, fr for French, enm for Middle English).

Quotes and blockquotes. 2: 3.7

  • Don't use <blockquote> for things that are not quotations.
    • In DP we use our /# ... #/ markup for anything that looks "special". But in PP we should probably change to <div> unless the contents really are a quotation from someone (or something) else.
    • But unfortunately, non-CSS users will lose out if we do this. See below.
  • The <q> element exists for short inline quotations.
    • Beware! It generates its own quote marks. [4]

Tables

HTML tables should be used only to represent tabular data, and not for visual layout.

The PG HTML rules require, among other things (this is just a quick summary):

  • Valid markup. 2: 3.2
  • Using "alt" for images and "summary" for tables so that people who can't see the images/tables will have an idea of what they contain.
  • No fancy stuff such as scripting or frames, which present many more accessibility issues.
  • Relative units. 2: 3.4
  • No forced colours, fonts, widths, etc.

Tables for tabular data

Screen readers handle tables in a special way. It's important to ensure that someone who can't see the table layout will still be able to understand the data. Refer to the W3C Web Content Accessibility Guidelines 1.0 on table markup for examples of the table markup techniques listed below.

  • Use table column and/or row header code, <th>, so that a screen reader recognizes the headers as such. 1: 5.1 [5]
  • Use <caption> [6], or if there isn't one, put one in the title attribute of the <table> tag.
  • If the table is complex (e.g. different levels of heading, sub-columns...): 1: 5.2
    • Use <thead>, <tbody>, <tfoot>. [7], [8] Note: According to W3Schools, "The <thead>,<tbody> and <tfoot> elements are seldom used, because of bad browser support. Expect this to change in future versions of XHTML." They are still perfectly safe to use: "unsupported" merely means some browsers act as if they weren't there, so you shouldn't attempt to style these elements in the CSS.
    • <col> and <colgroup>. [9]
    • scope and/or headers and/or axis. [10] Basically:
      • scope says what cells a header cell refers to, e.g. <th scope="col">.
      • headers says which header cells apply to a data cell, where you must have given each header cell an id.
      • axis is used to categorise cells.
  • If table headers are long, use the abbr attribute. 2: 5.6

The number of calories per 100g of food

Speech browsers may read the header before every cell it applies to(!) but may switch to the abbreviated version after the first row.
  • Use the summary attribute. 3: 5.5
    • Don't reuse the caption. Instead, describe the structure and trends that a visual scan would show [11].
  • Wrapped text: apparently older screen readers just read the whole thing line by line horizontally! Something to be aware of, though recall that the guideline is from 1999. 3: 10.3
  • Don't allow borders only to convey something.
    • For example, if the total of a column of figures is shown by a horizontal border separating the column from its total, consider using the title attribute on that cell.

Tables for layout

Avoid if possible! 2: 5.3 (This is a PG rule as well.)

Screen readers read the contents of tables "linearly," i.e., from left to right across columns. So, in order to be understandable to someone using a screen reader, a table has to make sense when read linearly.

For example (taken from the W3C accessibility guidelines), if a table looks like this on the screen: 

There is a 30% chance of               Classes at the University of Wisconsin 
rain showers this morning, but they    will resume on September 3rd. 
should stop before the weekend.

some screen readers could read it as: 

There is a 30% chance of Classes at the University of Wisconsin
rain showers this morning, but they will resume on September 3rd. 
should stop before the weekend.

Obviously this is something that we should avoid, if we can. However, the Guideline is from 1999, and even then it said that only "older screenreaders" behaved like this.

  • Sometimes we just can't help but use tables.
    • There will always be unusual things (family trees, parallel translations, diagrams, etc.) where we need to use tables.
    • In this case, the recommendation is don't use <th> etc, unless the cell really does refer to a whole row or column. 2: 5.4
    • The summary will need to be very good, especially where visual borders are used to show a tree structure, for example.
  • The Table of Contents/List of Illustrations debate: some people feel these are tables, others that they are lists.
    • I (Laurawisewell) think they're lists, because sometimes not just chapters but sections and even subsections are included—it's natural to make these nested sublists, whereas the table approach tends to make all of them just a "row", losing the idea of hierarchy even if you can mimic the appearance.
    • The CSS Cookbook gives instructions on how to use a list and right-align the numbers.
    • But I admit, for certain weirdly-laid-out ToCs even I resort to a table.

aria-hidden

Assistive technologies often announce elements such as horizontal rules, <hr>. These can be really annoying to a blind person. You can hide them from screen readers by adding an aria-hidden="true" attribute.

Miscellaneous

  • Anything for which you need the <pre> tag is likely to be an accessibility disaster.
  • If you find yourself using <span> a lot, think about whether one of <dfn>, <cite>, <ins> or <del> might be what you need. [12]
  • Parts of the title page that are all one phrase, like "By Professor V. Famous, Ab.C., D.E., Author of 'A Really Interesting Book' and 'A Rather Expensive Doorstop'", shouldn't be broken up into separate <p> or <h> elements.
  • The CSS display:run-in property should not be used for inline headings; it is part of a newer CSS specification than DP uses and implementation in browsers and ebook readers is spotty. Instead use something like the HTML below:
... danger in the case of such children is not over-pressure, but under-pressure.
   Intelligence tests as a basis for grading. Not only in the case of retarded or exceptionally bright children, but with ... 		... danger in the case of such children is not over-pressure, but under-pressure.</p>

<div class="like-a-paragraph"><h3 style="display:inline;">Intelligence tests as a basis for grading.</h3>

Not only in the case of retarded or exceptionally bright children, but with ...</div>

Without CSS

The document should still be usable without the CSS. This can conflict with "proper use of markup" and "avoid deprecated HTML".

  • The <center> tag is deprecated ... so without CSS nothing is centred.
  • The <blockquote> tag should be used for quotations, not for indentation ... so how do I distinguish other special passages without CSS?
  • Remember that CSS classes you create don't have to be used only with <span>s; styling an element that actually does something will ensure non-CSS users see a difference, even if not quite what's wanted. For example, if the book emphasised the words "Lord" and "God" using small-caps, you might use <em style="font-style:normal; font-variant:small-caps"> so that CSS browsers display what you want, while those without display the browser's default emphasis (usually italics).

Aural Style Sheets

http://www.w3.org/TR/REC-CSS2/aural.html

Tools and References

Browser / Operating System Tools

  • User stylesheet:
    • Choosing user stylesheet when you haven't created one (i.e. an empty stylesheet) is an easy way to see the document with all CSS removed, not just the header.
  • Outline view:
    • Some browsers can show you the structure of a document's headings, e.g. Firefox with the Document Map extension.
    • Some online tools also do this; see below.
  • Opera has many view options to try:
    • User mode (if you haven't specified a user style sheet, this turns off CSS).
    • Emulate text browser.
    • Accessibility layout.
    • Disable tables.
    • Show structural elements.
  • Turn off images.
  • Drag your window so that it's tiny.
  • Enlarge your font a lot.
  • Speech:
    • Your computer may have some built-in speech capabilities E.g. Mac OS X Voice Over. (But a proper screen reader is —I hope!—likely to do a better job.)
    • The most widely-used screen reader seems to be JAWS, which is windows-only and very expensive.
    • FireVox (a speech browser extension for Firefox) runs on all platforms and is free.
    • Talklets (a toolbar that speaks text you hover over) works on any browser & platform. A free account gets you 30 mins talk time per month.
  • Unplug your mouse. Are you wishing there was a key for ___ ?
  • Switch to white-on-black (or whatever high-contrast, no-colour option is provided). Can you tell which are links / transnotes / etc?
  • Turn on screen zoom. Are there things you'll never see unless you know where to look?

Automatic accessibility checkers

These should be used with common sense. Not all accessibility issues can be measured by machine, and many tools err on the side of producing copious warnings which may turn out to be false alarms. The point is not to ensure your page "passes" these tests, but to consider the issues raised by them.

  • WebXACT (also known as "Bobby") is probably the most famous.--As of February 1, 2008 no longer publicly available.
  • Ocawa is perhaps better. The site is in both French and English.
  • Cynthia Says and Hermish are similar, although check against Section 508 requirements as well as WCAG. However, they have a file-size limit which makes them unable to test some really big eBooks.
  • HTML Tidy's accessibility-check option can be set to 1, 2 or 3 so that it warns about possible breaches of Priority 1, 2 or 3 Accessibility Guidelines. (Also available as a Firefox Add-on.)
  • WAVE Accessibility Tool points out accessibility issues and displays your page with icons showing various tags and possible problems.
  • Structural markup checking: The Validator's extended interface can show the outline. W3C also offers the Semantic Extractor which is somewhat more detailed.
  • Web Accessibility Toolbar: As far as I know, this runs only on Windows, and is available for IE from Vision Australia. There is also an Opera version. WebAIM explain how to use it.
  • Colour:
    • Vischeck lets you type in a URL and view the page as it would appear to a colourblind person.
    • Graybit lets you view a page in grayscale, to check the contrast.
    • Colour Contrast Analyser tells you if two colours are sufficiently contrasting or not.

References

Abbreviations

References about images

References about tables

Retrieved from "https://www.pgdp.net/w/index.php?title=Accessible_HTML_eBooks&oldid=130873"