Ftrain is Accessible

By Paul Ford

At least, I think it's accessible.

Ftrain.com is a personal web site, and designed to be accessible to all readers. I've had to make some changes and screw with things a bit in order to make things work, so if something looks wrong to you, please email me.

• The following access keys are available:

  Access key 0

  Accessibility Statement

  Access key 1

  Home

  Access key 2

  Calendar

  Access key 3

  Table of Contents

  Access key 4

  Search

  Access key 5

  Index by Type of Author

  Access key 6

  First Lines of Poems

  Access key 7

  Copyright

  Access key 8

  About

  Access key 9

  Feedback

• There is structured markup on these pages. H1 is used for the page title (Ftrain.com). H2 is used for section titles. H3 is used two ways: for sub-titles inside a section, and in the navigation, for sub-sections of the navigation.
• Relative links to take you home, up, and to the first-in-section, previous, next, and last-in-section pages are embedded in the page. These can be seen in recent Mozilla browsers in the “site navigation bar.”
• Links have titles with navigational attributes, indicating whether they are a cross-reference, pointer to an external site, or pointer to a sub-section of the current section. Images from about 2000, and most of the images from before that, have alt tags.
• This page uses Cascading Style Sheets with relative (by percentage, however, not by size names) font sizes; users are encouraged to increase or decrease font size to their comfort - it looks fine at 200% or more. Cascading Style Sheets (CSS) are not needed to view any content. Broken Cascading Style Sheets implementations, like that in Netscape 4.X, are sadly not supported. The q tag is not supported, due to really evil browser support issues, and the light-blue links may be difficult for those with color-blindness to perceive; some of these issues will be addressed in future adaptations of the code.
• I believe these pages are Bobby AAA, WCAG AAA, and Section 508 approved, or awfully close. I am honestly not 100% sure if they are or not, but in reviewing the Bobby auto-analysis output, and following Mark Pilgrim's guidelines (see below), I think I've covered the bases. As I continue to develop the code beneath Ftrain, I'll look for tweaks and simplifications. Most importantly - since this is a personal web site, and open to criticism, if you find these pages difficult to read, please tell me.
• All pages on this site are HTML 4.01 Transitional, and in English. (XSLT1.0 does not support XHTML1.0 with all the display hacks natively; when I move to XSLT2.0, XHTML1.0 will be automatically supported.)

Ftrain has always (i.e. for 5+ years) made an attempt to accommodate those using text-mode browsing, usually through special scripts that dynamically parsed content, and a number of people do read it that way, particulary, for some reason, Canadians.

Now, however, the dynamic, catastrophic interplay of web developers, CSS experts, and browser-makers has resulted in enough kludges, workarounds, and genuinely thought-about solutions that it is possible to build a single set of pages that work fairly well however they're viewed, whether by advanced jet-set browsers like Mozilla and I.E., text-only browsers like W3M and Lynx, or, I hope, screen-readers like JAWS. The odd kids out are Netscape 4.x, in which pages such as these explode all over the place, and Opera, which has some odd behaviors but works most of the time.

Ah well. I cannot please everyone. If a reader is using an outdated, broken software product, like Netscape 4.x, then the onus is, somewhat unfairly, on them to upgrade. However, if someone is using a software package that is the best possible tool for their particular way of reading - i.e. a screenreader for the blind - then I will try to conform to that standard - not perfectly, perhaps, but well enough.

So accessibility has long been the goal, but I've been too lazy to look into the specifics. Luckily for me, Mark Pilgrim created a web site called Dive Into Accessibility which offers a checklist for making your site easier to read for a variety of individuals with different needs, and then Michael Barrish took up Mark's challenge, and made his own site accessible. Since I have my own metadata-driven publishing system based entirely on XML, and I estimated that compliance with most guidelines would probably take 3 hours or so to put together, it was inexcusable for me not to be compliant.

Thankfully, those few hours really were only a few hours - I've been alt-tagging and meta-data-ing for a while, so adding some extra content to my template system was fairly straightforward. I'm sure I'm missing something, but I am able to say with moderate confidence that the 1000+ separate pages on Ftrain should be, in their greatest portion, readable to nearly anyone.

There are, I know, images from 1997 that don't have alt tags, and instead of proper div or hr tags I use three hashes to indicate a section divide, but the important things - that the fonts can be increased or decreased in size (I like to read sites at 200%, far back from the monitor), that the story comes before the navigation, that things flow in a simple, linear way as well as in their gridded form, as well as particulars like accessibility keys, relative links, and so forth, are all in place.

One note of interest - a lot of accessibility concerns overlap naturally with the general direction of XML-based content development. For instance, XLink links provide a much larger range of options for where and how links point to URIs than the regular href element - and can also support linkbases, which can be extremely metadata-rich databases of links. This leads to a change in approach: rather than having links as elements in a page, you include references to a database of links (which can be, among other things, bidirectional), which means that issues of, say, link consistency can be avoided - and adding title tags is no longer required, as a full summary of the link can be included in the link database, and propogated in a uniform manner on a link-by-link basis. Centralized databases of content are useful for ensuring the consistency of content - they can help you name, and refer to things, consistently. One of the most valuable parts of the LaTeX system for typesetting is the bibliography functionality - and large, shared bibliographies allow citations databases to be built up effortlessly. A single ID, a single reference, and suddenly data can explode out of anywhere.

The point? That accessibility, in addition to being a good thing to provide, is one facet of a larger range of issues about connecting data, and that humans and computers can all benefit from a little more metadata.

Thanks to Mark and Michael for the indirect goading.

And a big shout out to God.