Tagged with "accessibility"

Screen Readers Suck!

Dave Child — Thu, 15 Sep 2005 12:58:00 +0100

Accessibility has now become a major issue in web design. One benchmark of an accessible site is that it works in common screen reading programs. However, screen readers are making the job of conscientious web designers harder than it should be.

Accessibility has been brought to the forefront of the minds of many designers and developers over recent years. In many countries there can be legal repercussions if you have built a site and not made a reasonable effort to accomodate disabled users. One of the most often discussed parts of this process is making your site work with screen readers.

Screen readers are programs that are designed to read the contents of pages and programs to users, so that those with sight problems can still use computers. With most software, they work well. Microsoft Word, for example, works well with screen readers. However, on the web it is a very different story.

(Please note - I am well aware screen readers are very valuable to many web users and am not trying to ridicule them - just trying to help make the people that create screen readers shoulder some responsibility for making the web accessible.)

Screen readers have many problems when it comes to reading websites, aside from just the code used by web designers and developers. It should be simple enough for the makers of these programs to solve the problems with their software, but rather than there being pressure on them to do so, the pressure is on designers and developers to create sites that work perfectly with these sub-par applications.

The first major problem with screen readers and the web is that the web is a huge collection of very different documents. Every page has different code behind it, and every site has its own idiosyncracies and potential problems for a screen reader. Some sites use images without alt attributes, for example, forcing screen reader users to listen to "spacer.gif" over and over again. Some use bad link text, or have huge navigation systems without any method for the screen reader user to avoid hearing that navigation system read out to them, page after page after page.

These specific problems are down to accessible coding, but once you have a site that meets at least the basic accessibiltiy requirements, the problem is far from over. Meeting minimum accessibility requirements does not, by a long way, ensure that users of screen readers (and other assistive technology) will actually have a pleasant experience using your site.

CSS and modern web technologies have systems in place for resolving this issue. Media types in CSS allow you to specify different style sheets for a site depending upon what type of user agent is visiting the site, braille and speech being the two most closely related to accessibility. Using these media types, you can set specific parts of the page to be treated differently by screen readers. For example, you could hide all decorative images or re-order the page so content is first.

The title attribute of HTML allows you to provide more information about an element. Screen readers are not obliged to read the contents of the title attribute instead of the element contents, but it is widely accepted that for most elements in most circumstances the title attribute is very useful. Perhaps the screen readers should read both, or give the user an option. As it is, they allow the user to select whether they would prefer to hear the title or not, but only for links and images - no other elements.

HTTP headers are also designed to allow user agents to determine what content they are returned from a server, specifically with the HTTP_ACCEPT header. Internet Explorer, unfortunately, simply lies about what it can understand in this header, which seems to have devalued it somewhat. That said, the value of the header is immense. If a user agent, such as a screen reader, were to correctly identify what it can and cannot receive from a server, the server would be able to send its response in the best possible form. For example, if you are offering an audio version of an interview in mp3 form, and the HTTP_ACCEPT header was used properly by user agents, you would be able to send a text transcript of the interview to those users who cannot interpret MP3 files. The same applies to much of the content on the web.

Though it would not be ideal, designers and developers could achieve the same thing - delivering content appropriately to user agents depending on what they can use - if screen readers were to identify themselves correctly with a recognisable HTTP_USER_AGENT header. That would enable developers to identify requests from screen readers and send back the correct content.

The excuse generally used is (with both this and the HTTP_ACCEPT issue) that screen readers do not render web pages and are not user agents - they are, instead, simply programs that read the contents of web pages once rendered by a browser. However, there is no good reason screen readers could not modify the values of these HTTP headers before they are sent. Really, there is no good reason the makers of screen readers could not use an open source rendering engine such as Mozilla or KHTML in their products, and become web browsers in their own right as well.

Consider this example - I have a breadcrumb system on a site, using "»" as the separator between the breadcrumbs. I like that symbol, and I'd like to keep using it. Unfortunately, a screen reader will read that literally as "right double angle bracket". This could mean my breadcrumb trail, though it looks nice enough, sounds through a screen reader like: "home right double angle bracket products right double angle bracket betty boop right double angle bracket bobbler". Not ideal - and only really fixable by changing the separator or using an image instead of text - but that is how things currently work.

However, if screen readers were able to understand the CSS media property, I could hide those symbols from screen readers. If the title attribute were used better, I could set it to nothing or "separator", making the breadcrumb trail far more useful. If neither of these were possible, I could at least serve a slightly modified file to the screen reader user, with the symbol replaced by something more useful, based on their HTTP_USER_AGENT.

The irony with all of this is that if screen readers (or rather web readers) were to make life easier, more and more designers and developers would ensure that their sites work perfectly with screen readers. More and more people may well then make use of these technologies.

I can appreciate that there may be financial constraints on the creators of these programs, and that improving how they handle web sites may not be at the top of their list of priorities, but these are still important flaws in screen readers and should be fixed. I can't help but think that if the web design community were to put pressure on the people that make these programs, it would be easier to create accessible web sites. More people would then create accessible websites (or improve the accessibility of their already-accessible sites), giving the users of screen readers a better experience on the web.

Flesch-Kincaid Reading Level

Dave Child — Wed, 07 Jul 2004 14:17:00 +0100

Functions to count the number of syllables in a word or sentence, and work out the readability of text.

PLEASE NOTE: This code is now considered out of date. An updated version has been released under an open source license as a Google Code project: php-text-statistics. There is more about this change in the post Readability Code Open Sourced.

A tool for checking the readability scores of text is available - this article covers the functions behind that tool.

Calculations based upon word structure can tell you a fair bit about the text on your site, most notably the readability of your copy. A lot of sites have text on them that is simply too advanced for their users, which is as useful as having no text at all.

It is therefore usually a good idea to check the copy on your website as thoroughly as possible. Spelling and grammar should be checked as a matter of course. You should also check how difficult your text is to read. If a user cannot easily understand what they are reading, they will leave the site and find one they can comprehend.

The following are two calculations that can give you an indicator of how easy your text is to read.

Flesch-Kincaid Reading Ease

The Flesch-Kincaid reading ease score is worked out using the following calculation, which gives a number. The higher that number is, the easier the text is to read.

206.835 - (1.015 * average_words_sentence) - (84.6 * average_syllables_word)

The function you will need to use to work this score out (in addition to the three at the bottom of this page) is:

function calculate_flesch($text) {
    return (206.835 - (1.015 * average_words_sentence($text)) - (84.6 * average_syllables_word($text)));
}

And you can call the function like so:

$flesh_score = calculate_flesch($text);

Flesch-Kincaid Grade level

The Flesch-Kincaid grade level is a similar calculation, however gives a number that corresponds to the grade a person will need to have reached to understand it. For example, a Grade level score of 8 means that an eighth grader will understand the text.

(.39 * average_words_sentence) + (11.8 * average_syllables_word) - 15.59

The function you will need to use to work this score out (in addition to the three at the bottom of this page) is:

function calculate_flesch_grade($text) {
    return ((.39 * average_words_sentence($text)) + (11.8 * average_syllables_word($text)) - 15.59);
}

And you can call the function like so:

$flesh_score = calculate_flesch_grade($text);

Both of the functions above make use of the functions below, so these will need to be included in your scripts in order for either function to be used.

Each score returned is not perfectly accurate. Unfortunately, it is not always possible to work out the number of syllables in a word programatically, and not always possible to correctly calculate the number of words per sentence, or indeed number of sentences, in text. However, the function will return a close approximation of the value - certainly good enough for our purposes.

Ideally, you should aim for a reading ease of around 60 to 70 (equivalent to a Grade level of around 6 to 8). The nearer 100 your text scores, the easier it is to read (and conversely, the lower the grade score, the easier the text is to read). Comics, for example, are usually in the 90s. The Harvard Law Review scores in the low 30s. Legal documents are usually lucky to make it into double figures.

The functions you will need in order to calculate the Flesch-Kincaid reading ease or Grade level of text are:

function average_words_sentence($text) {
    $sentences = strlen(preg_replace('/[^\.!?]/', '', $text));
    $words = strlen(preg_replace('/[^ ]/', '', $text));
    return ($words/$sentences);
}

function average_syllables_word($text) {
    $words = explode(' ', $text);
    for ($i = 0; $i < count($words); $i++) {
        $syllables = $syllables + count_syllables($words[$i]);
    }
    return ($syllables/count($words));
}

function count_syllables($word) {

    $subsyl = Array(
        'cial'
        ,'tia'
        ,'cius'
        ,'cious'
        ,'giu'
        ,'ion'
        ,'iou'
        ,'sia$'
        ,'.ely$'
    );

    $addsyl = Array(
        'ia'
        ,'riet'
        ,'dien'
        ,'iu'
        ,'io'
        ,'ii'
        ,'[aeiouym]bl$'
        ,'[aeiou]{3}'
        ,'^mc'
        ,'ism$'
        ,'([^aeiouy])\1l$'
        ,'[^l]lien'
        ,'^coa[dglx].'
        ,'[^gq]ua[^auieo]'
        ,'dnt$'
    );

    // Based on Greg Fast's Perl module Lingua::EN::Syllables
    $word = preg_replace('/[^a-z]/is', '', strtolower($word));
    $word_parts = preg_split('/[^aeiouy]+/', $word);
    foreach ($word_parts as $key => $value) {
        if ($value <> '') {
            $valid_word_parts[] = $value;
        }
    }

    $syllables = 0;
    // Thanks to Joe Kovar for correcting a bug in the following lines
    foreach ($subsyl as $syl) { 
        $syllables -= preg_match('~'.$syl.'~', $word); 
    } 
    foreach ($addsyl as $syl) { 
        $syllables += preg_match('~'.$syl.'~', $word); 
    }
    if (strlen($word) == 1) {
        $syllables++;
    }
    $syllables += count($valid_word_parts);
    $syllables = ($syllables == 0) ? 1 : $syllables;
    return $syllables;
}

Examples

The following are two examples of text and the readability of that text.

The first is an excerpt from [url=http://www.online-literature.com/grahame/windwillows/]The Wind in the Willows[/url]. It is what most people would call easy to read:

"There's Toad Hall," said the Rat; "and that creek on the left, where the notice-board says, 'Private. No landing allowed,' leads to his boat-house, where we'll leave the boat. The stables are over there to the right. That's the banqueting-hall you're looking at now - very old, that is. Toad is rather rich, you know, and this is really one of the nicest houses in these parts, though we never admit as much to Toad."

For reading ease, this scored 69. It also had a Grade Level of 7. This particular passage of Wind in the Willows scores at almost exactly the same level web page text should ideally score.

On the other hand, the following (both this text and the above were generously provided by [url=http://members.dca.net/slawski]Bill Slawski[/url], by the way) is an excerpt from a legal document, and would give many a headache:

The foregoing warranties by each party are in lieu of all other warranties, express or implied, with respect to this agreement, including but not limited to implied warranties of merchantability and fitness for a particular purpose. Neither party shall have any liability whatsoever for any cover or setoff nor for any indirect, consequential, exemplary, incidental or punitive damages, including lost profits, even if such party has been advised of the possibility of such damages.

This scores an incredible -1 on the reading ease scale. The Grade Level required to read it? 22. This is what you could widely consider the most unreadable text you could add to a web page.

These are, perhaps, extreme examples, but they should give an idea of the differences between good and bad text on a web page.

28k and 56k Modem Emulator

Dave Child — Tue, 29 Jun 2004 01:12:00 +0100

Regardless of your connection speed, this will show you how your site loads on PCs with older connections.

PLEASE NOTE: This tool has been taken offline and the code has been released as an open source project: modem-emulator. There's some background on the change here.

Some designers have taken the rise of broadband to mean that graphic intensive pages are now acceptable, that 600k Flash intros are suddenly desirable, and that otherwise bombarding the user with bandwidth-hungry sites is commendable. Sadly, plenty of users are still on dial-up, using 28k, 33.6k or 56k modems, and it's all too easy to forget that when you're surfing on a high speed office connection or even your home broadband.

With that in mind, I've put together a ~~modem emulator (or is it a modem simulator?)~~ throughput throttling proxy (apparently). In theory it should allow you to view your site through the eyes of a user with a slower connection. In practice, it isn't perfect, but might give you an idea of how some of your users actually experience your site.

A word of warning as well - the tool is tested (though not extensively) with sites that I use or have built. There will be unusual sites that don't work with this tool (flash is so far untested for example). Please email me if you have any problems.

The emulator suffered a great deal of abuse in the past, mainly by people wanting to bypass work internet filters. Unfortunately, that has meant that I have had to add a few features to the tool. The primary change, for my own sanity, is a blacklist of URLs. I hope to not have to change this to a whitelist, but that option is available should the need arise.

To use it, simply enter your URL and the speed you'd like to see the site go, and the script will show you the page desired loading as it would on a slower connection.

The tool has been taken offline, and the code has been released under an open source license. There's some background on the change here.

Finally, someone is bound to ask, so to save myself the time answering later - no, this cannot show you how your site will load on a faster connection than you have yourself :).

Update 29 December 2006

The emulator has been tentatively reinstated with some features to enable me to manage it.