Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

barbie (2653)

  reversethis-{ku. ... m} {ta} {eibrab}

Leader of [] and a CPAN author []. Co-organised YAPC::Europe in 2006 and the 2009 QA Hackathon, responsible for the YAPC Conference Surveys [] and the QA Hackathon [] websites. Also the current caretaker for the CPAN Testers websites and data stores.

If you really want to find out more, buy me a Guinness ;)

Memoirs of a Roadie []
CPAN Testers Reports []
YAPC Conference Surveys []
QA Hackathon []

Journal of barbie (2653)

Wednesday March 17, 2004
08:58 AM

The Accessible Web

[ #17938 ]
A friend recently asked me about whether I knew about the JAWS screen reader. Unfortunately I'd never heard of it, although I suspect another friend of mine (who works for the RNIB and is blind) may use it. However, it did prompt me to wonder.

In October 2004, the final phase of the DDA comes into force, which will mean many websites will need to be changed so they don't fall foul of the law. Especially seeing as the RNIB have already funded cases that have appeared in Crown Court. Allowing accessibilty to people who use screen readers and the like, I think its quite an important area of web design, as it enables as many people as possible to view your web pages. Previously my friend at the RNIB has made comments on my websites to prompt me to fix tags and such. But that was back in the days when I was just starting (1998). However, it should be noted that only services offered via the web (eg Airline ticket booking) are currently covered by the Act.

So I wondered if there is anything (in Perl) that can check your HTML to see whether it meets the requirements. As yet I haven't found anything. My thought was to create a module called HTML::Accessibilty, which can be called similar to Test::Pod, and can report on failings, missing titles, tab indices, etc. I've gone so far as to find a a few really useful sites. So when I have more time I may attempt this, unless someone with CFT decides to give it a go before me.

Interesting aside: use.perl striped all the 'title' attributes above, which are part of the accessibility requirement.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • There is Bobby [] which is Java based. It's not perfect but it's good at pointing out possible problems.

    Bobby tests for both W3C WAI [] or US 508 [], but it's not perfect. I don't know of other tools, if anyone else does I'd like to know about them.

    I beleive that Betsie [] the BBC's screen reader is Perl based, and open-source, but it's a little antiquated and it does struggle with really awful sites.

    I believe that use Perl; hijacks the title tag to show the TLD of the link, if you have your settings configured t

    -- "It's not magic, it's work..."
    • Thanks for the links will look into them. I did have the TLD flag setting in my preferences, so will have to see if that makes a difference in my next link :)

      Decided a better name for the module might be HTML::Lint::Accessible seeing as it really is just an extension of HTML::Lint [].

      • I've used Bobby on and off for a while. It's not perfect, it often says thinks like "have you checked this?" rather than tell you anything specific. As a result it reports both false positives, and misses actual problems, but it's a good first line.

        I think that the more recent HTML Tidy [] does some WAI checks too. As it's now a c library, and accessabile from Perl, (HTML::Tidy []) that's another avenue to look at.

        At the end of the day, automated tools can only go so far, but they are a good place to start.

        -- "It's not magic, it's work..."
        • To be fair, I don't think any automated tool can avoid having false positives or false negatives, barring amazing advances in AI. For example, a tool can't know whether an image is purely decorative (and thus needs an ALT attribute of "") or whether any ALT text is meaningful (as opposed to some mindless combination of filename and file size, as some authoring tools have been known to generate).
          • This is true, it's an automated tool, and it can't know if object on the page is accessible, important or trivial padding. It's a good first line, but that's all.

            Many web automated web page creation tools do produce awful and inaccessible web pages, so at the end of the day all pages need to be checked by hand to be sure that they are good. Like you said simple minded rules in Dreamweaver are not going to make web sites accessible, people need to think for them selves to produce good sites, instead of rel

            -- "It's not magic, it's work..."
    • I beleive that Betsie the BBC's screen reader is Perl based

      Ew, regex based HTML parsing []!

  • I was in a project some time ago that involved converting ~20.000 HTML pages of inferior quality (coded by civil servants of various departments) to valid, WAI-conform HTML.

    We used tidy to validate WAI-level 1 conformity and it worked quite well. (although we used the command line version, as the lib wasn't really finished then).

    To convert the messy HTML to valid HTML we used HTML::Parser and a hell lot of code specially tailored to this project. I do not think that you can write up a generally working

    • I wasn't thinking of a converter, more a simple checker, that can spot whether titles appeared in links, or that tabindex entries didn't clash, etc. If HTML::Tidy [] does that then so much the better. I can't see me ever having time to write a converter, as that would be way too much work for all the edge cases that might appear. A list of simple warnings is much better, so that you can fix your templates [1] by hand.

      [1] I couldn't envisage editing 20,000 pages!

  • checky [] will let you run most/all of those tools (and many others) at the click of a mouse or press of a button.