I found it difficult to get a complete understanding from the resources available on the web, but have put together a high level support table based on information I could glean. If you have any further information or find any inaccuracies please comment.

Practical support

Practical support for screen readers means that a browser can be successfully used to browse and interact with commonly encountered web content, using current versions of OS level screen readers such as, on Windows; JAWS, NVDA, Window Eyes. On Mac OSX and iOS; VoiceOver. On Linux; Orca and on Chrome OS; ChromeVox.

table legend

• “supported” means that the browser is usable with a screen reader on the operating system (OS).
• “partial support” lacks support for some important features. For example, Chrome on Windows supports browsing using JAWS, but does not support the select element or form control labelling using the label element.
• “not applicable” means the browser does not run on the OS
• “not supported” means the browser does not have practical support for screen readers on the OS.

Note: The table refers to the current (06/02/2012) versions of browsers and current versions of operating systems.

Practical screen reader support by browser and OS (06/02/2012)

Windows
OSX
Linux
IOS
Android					(webkit)
Chrome OS

References:

• Comparison of Web Browsers
• Comparison of screen readers
• Mobile Operating Systems
• The Current State of Cell Phone Accessibility

It is true (as far as I know) that there is no currently available dedicated service or software for checking 4.1.1 Parsing. What I do and advise clients to do is use the W3C validation service to check their code as the checks required for parsing criterion conformance are a subset of the checks that are made when validating HTML code.

Identifying relevant errors and warnings

A problem with using a standard HTML validator to check for this subset is that many other conformance errors and warnings are also reported and while these may or may not be important to fix, they are not a requirement within the scope of the success criterion. What I have been doing is checking pages against the HTML5 doctype as this minimizes the occurance of errors and warnings that are unrelated to parsing, but still a page can contain many non parsing errors, making it difficult to identify the relevant results.

I have also had discussions with Mike Smith (W3C Nu Markup Validation Service) and Henri Sivonen (Validator.nu) about providing a method to filter conformance results to display only parsing issues. There are apperently some design reasons why this would be difficult (not impossible) from a backend code perspective, so I thought a reasonable place to start would be with a client side script that filtered the display of results from a validator.

Parsing error bookmarklet

The WCAG parsing only bookmarklet is an experimental script that loops through the results displayed when using W3C Nu Markup Validation Service. It looks for certain text strings in the results output and if it does not find them in the text for a particular result it hides that result using CSS display:none.

Check results other than the followoing are filtered:

• Elements have complete start and end tags
• Elements are nested according to their specifications
• Elements do not contain duplicate attributes
• Any IDs are unique
• Unquoted attributes (under certain circumstances)
• Duplicate attributes
• Mismatched quotes on attributes
• Attributes not space seperated
• Mismatched element start and end tags
• malformed attributes

Trying out the parsing only bookmarklet

1. save the WCAG parsing only as a bookmark.
2. open the W3C Nu Markup Validation Service in your browser
3. validate a page (test page)
4. activate the bookmarklet
5. To view the unfiltered list of results again – refresh the page
6. you can download the parsing.js code

WARNING

This is an experiment only, due to various constraints the method used to filter the results is not the most robust as it relies upon text string matching. Do not rely upon it.

Note: this experiment would not have been possible without the help of my friends and colleagues Hans Hillen and Gez Lemon, who although they thought the method used was crappy, helped me anyway.

HTML5 codifies the authoring of inaccessible content

Furthermore we still have the authoritative document for understanding how to use and implement HTML, illustrating and advocating title attribute use in terms that promote and codify inaccessible content. While at the same time the HTML5 specification does not mention the real world documented usage methods for the title attribute that actually help users with disabilities, because the editor of HTML5 refuses to allow it.

Examples of HTML title attribute use and abuse

In the linked document title attribute usage examples I have provided some data of title attribute use on a range of popular sites. The examples illustrate that the title attribute is widely misused.

When to use the title attribute: simplified

1. Do not use the title attribute, on any element, for any text  that you want all users to have access to.
2. Only use it to label a form control when the same text is provided as visible text.
3. Do not use it on a link to provide information that may be important to any user.
4. If in doubt, read: Using the HTML title attribute

Further reading:

• Reasons to not allow the title attribute to be used as a substitute for the alt attribute in HTML5
• Reason to not promote the use of the title attribute for footnotes in HTML5
• Reasons for not promoting the title attribute as a container for captions in HTML5
• title attribute definition does not match reality

Request for timely implementation of the new standards

Chairperson Melick, honorable members of the United States Access Board, good morning.  My name is Brian Landrigan and I am the director of sales and marketing for The Paciello Group, a small consulting firm.   Our headquarters are in Nashua, NH, and we are solely dedicated to providing consulting services in the areas of application accessibility for software development companies and website accessibility for companies needing to create accessible web properties.   I appreciate and thank the board for this opportunity today to provide public comment on the second Advance Notice of Proposed Rulemaking that includes a revised draft of updated accessibility requirements for information and communication technology covered by Section 508 of the Rehabilitation Act and Section 255 of the Telecommunications Act of 1996.

Negative impact of out of date standards

First, I would like to commend the Access Board and the Telecommunications and Electronic and Information Technology Advisory Committee for their diligence in developing and bringing to public the updated requirements.  In our business, we are acutely aware of how the older standards lacked acknowledgement of the vast changes in information technology that has occurred over the past decade.   My peers and I at The Paciello Group applaud your efforts to make the internet and information technology in general more accessible for the most disengaged segment of our population – people with disabilities.   The simple act of creating new standards and opening the dialogue within industry is sparking a fervent interest in many of our clients that did not exist prior to this.   We are experiencing first-hand a new energy and enthusiasm for providing a more open technology world.  The original announcement from TEITAC in April, 2008, was warmly welcomed by our business, our clients and our competitors.   We see that as a watershed date for the accessibility business.

Slow progress affecting business uptake

Unfortunately, nearly 4 years have passed since that announcement.  While we all understand that sometimes government moves at a slower pace than commercial businesses, the fact that the proposals of TEITAC have not yet been implemented is disappointing.    Some of our clients are openly questioning now whether they needed to spend the funds necessary to implement the changes we and TEITAC recommended.  To us, there are three points to be made regarding this:

1. The delay in implementing the Section 508/255 ICT recommendations is having an adverse effect on our business and the business of consulting companies such as ours who have invested in training, development, tools and other resources to become expert at accessibility.
2. We are not looking for business justifications for accessibility…things like cost of ownership models or return on investment.   It is our responsibility, selling accessibility consulting services, to create that information for our clients.   We need you to focus on the guidelines.
3. Further delays are discouraging and deterring many companies and people who are accessibility proponents.   These are the people you are failing to support by not implementing the new guidelines.

Delay in implementation negatively impacts all stakeholders

I would like to take a few moments to expand on these points.   First, let me discuss the adverse effect on our business.  I recognize this is somewhat self-serving.  However, our entire business is accessibility consulting, built on the belief that companies doing business with the federal government would need services such as we offer because federal agencies would insist on conformance to the new Section 508 standards.  We perceived a knowledge gap between the existing guidelines and the new guidelines and moved quickly to fill that gap and we have been successful.  We continue engaging prospects and clients eager to learn how to comply with the federal procurement mandate and how to create a more accessible technological environment for their customers.  However, with the delay in adoption for the new standards, we have clients who are second-guessing their decision to implement the changes to their development and testing departments based on our recommendations.   Further, we are now seeing clients postpone adoption of the recommendations, literally waiting to see if the adoption of the new Section 508 guidelines will be further delayed or even canceled.   Please act swiftly to counter this perception.

Secondly, the business justification for adoption of the new Section 508 standards.  We are concerned that the lag time in adopting the new standards is related to getting them “perfect”.    There are numerous comments and concerns regarding cost of implementation of the new guidelines and whether this places an undue fiscal burden upon agencies and businesses.   This delaying tactic is frequently employed by special interest groups to make us question whether a practical application of something new is reasonable.  This has occurred in the past in discussions for equal rights for minorities, women and other disenfranchised groups.    Our point is that the implementation cost should be an area that the free market, composed of experts in accessibility and our clients is clearly capable of creating a value proposition demonstrating any cost is outweighed by additional benefits.  We can demonstrate that today and this should not be a gating factor in the new Section 508 moving forward.

Thirdly, you are exhausting well-minded people who want to embrace accessibility and universal usability by further delaying the implementation of the new guidelines.  In our work, we come in contact with product managers, developers, quality assurance professionals, procurement specialists, directors of accessibility, CEOs, COOs, CFOs, etc.  A number of them are excited and enthusiastic about putting their products and their companies on the front line of greater access and opportunity for people with disabilities.   They are doing it for a myriad of reasons; it is the “right” thing to do, it is the law, it enhances their business, it improves their marketability, it is a selling point.  Having people and agencies within their government who feel as they do provides them with a satisfaction that we are all “pulling together on the same end of the rope”, that we are sharing a common goal.  This is immeasurably helpful when they encounter others within their own company opposed to accessibility for financial or logistical reasons.  As many of you can empathize I am sure from your own experience, they are “fighting the good fight” and it is rewarding.    But when you are on the front lines, fighting the good fight for a common cause, it is imperative that you know you have the support of those “behind the lines”.  Without that support, the fight is empty and impossible.  Without the passage of the new Section 508 standards, you are telling those “front line” people that you are questioning your resolve….that you are hesitating to wholeheartedly support them.   This is not a good message.

Please move these important standards forward

Once again, I want to personally thank the members of the TEITAC committee for the enormous effort put forth to get us to this point.  I also want to thank the Access Board and its staff, as well as other federal agency volunteers for their diligent efforts.  This is significant progress of which you should all be justifiably proud.  The new Section 508 standards will provide a dramatic improvement in the lives of people with disabilities, particularly in respect to access to technology and information with respect to a more open government.  In that case, we all win.   Please re-energize yourselves and move this very important set of standards forward so everyone can enjoy the benefits.   Thank you for your time and consideration.

Anyone can join the W3C HTML Working Group

Want to have a say in the development of the language of the web? Then join W3C HTML Working Group, here’s how to do it:

I encourage everyone interested in the development of HTML5 to take part. If you don’t take part, and the language develops in a way you don’t like, then you have but yourself to blame.

Taking part in the group is not a big commitment. You can spend as much or as little time contributing; you don’t need to read every e-mail on subjects you don’t care about, you don’t need to call in or attend face-to-face meetings. In fact, the W3C has stated in the group’s charter that no binding decisions will be made at meetings; you are guaranteed equal say whether you are present or not.

To join, you have to go through the following steps:

If you don’t work for a W3C member organisation:

1. If you do not already have a W3C Access Account login and password (check if there is an account associated with your address), complete the Public Access Request Form. You should receive your W3C login name and password within two (2) business days.
2. After you receive your W3C login name, complete the W3C Invited Expert Application. You should receive a reply within ten (10) business days. If your request is accepted, you will receive an invitation with additional instructions for formally joining the group.
3. You will then be able to complete the form for joining and participating in the HTML Working Group as an Invited Expert, at which point you are a bona fide member!
4. Remember to read the HTML Working Group Charter, invited expert and collaborators agreement and Policy for Approval of Invited Experts documents.

You will also be subscribed automatically to the group’s mailing lists.

If you do work for a W3C member organisation:

The steps above don’t apply to you. Instead, you have to follow these instructions.

What about HTML5 Accessibility?

The W3C HTML Working Group has a dedicated accessibility task force (mailing list) working on a range of HTML5 accessibility issues:

• ARIA Integration
• Bug Triage
• Canvas
• Media
• Text Alternatives

Note: Any HTML working group member can join the accessibility taskforce and are encouraged to!

Based on Ian Hickson’s post (2007) and Instructions for joining the HTML Working Group

The Canvas API mailing list

This list is intended to serve as a dedicated thread for matters specific to the Canvas API and its intersection with other DOM interfaces and with markup.

The bulk of the work the past three years has been in advocating for accessibility frameworks. There has been exhaustive discussion with developers from several browser vendors, stemming from an early recommendation that the Canvas sub-tree be supported.

All accessibility frameworks are dependent on the ability to have an object model to provides a hierarchy that provides context to a user and which can provide interfaces to an assistive technology [for example] a 2D chart has dynamically changing data it could be replaced with an HTML table marked asa live region or even a grid.”

Accessibility remains unresolved

Programmatic access is a conformance principle of the Web Content Accessibility Guidelines.  Accessibility remains unresolved and an issue in last call procedures for HTML5 as of December 2011:

“There are numerous accessibility issues/bugs that will need to be addressed, before the spec. leaves last call”

• Concerns and unaddressed issues for the HTML 5 specifications
• Status of Canvas A11y Bug Reports

3 years on

Work on resolving Canvas accessibility issues took shape in July 2009.

It has been decided to form a task force to work on specifying additions to the CANVAS API, that will result in canvas content being natively accessible.

The merits of supporting Canvas and DOM tree interaction were discussed in a late 2009 accessibility call.

[Supporting] focus for ‘widgets’ inside the canvas could also be handled via DOM, by adding a requirement that anything inside the canvas’s DOM subtree with a tabindex must still participate in the tab cycle and produce focus events

Canvas element sub-tree support

Microsoft added support for focus events inside the Canvas element sub-tree in their release of IE9. Other vendors are expected to follow suit.

WebKit reviewed but eventually rejected an early patch in February 2011.

[Do not use RenderReplaced,] the best way to fix it is to make RenderHTMLCanvas a RenderBlock and more like a form control

Focus ring support

drawFocusRing, a new Canvas Context 2d method, was added to the specification. It’s purpose to display a focus box within the canvas element when focus events are received.

Currently, no vendors support the drawFocusRing method, though there is broad consensus that it should be supported.  Mozilla has been discussing support for some time. Their bug report follows the whatwg specification, which recommends two methods: drawSystemFocusRing(element) and drawCustomFocusRing(element) whereas the w3c specification recommends one method with an optional boolean attribute: drawFocusRing(element, boolean).  The drawFocusRing method was chosen over <map> element / useMap extensions proposed in early 2010.  drawFocusRing demonstrates that the Canvas sub-tree is available for focus management and that the Canvas 2d path API is being exposed, in some manner to the system accessibility API. It’s an important milestone.

Canvas clickable regions

The various issues that have been discussed are catalogued on a W3C wiki page.  There is consensus that the useMap property, based on HTML4 <map>, should not be used with Canvas. The competing focus ring and caret tracking proposals were moved forward.  Unfortunately, the group has had mixed consensus about approaching clickable regions in Canvas. We’ve not been able to develop broad consensus. Many spec editors and developers who work for [browser] vendors have suggested that use cases involving interactive elements are not appropriate uses of HTML5 and should not be encouraged. There has been strong push-back suggesting that Canvas not be used for such cases and that SVG be used.

[In cases where] you only have a few active regions, then you probably only have a few shapes, and you can use SVG

Just use SVG

This lead to a lengthy series of threads about the pros and cons of SVG and Canvas development and the repeated suggestion that interactive regions in Canvas should not be encouraged (nor supported) by [browser] vendors, as they are better suited by retained vectors in SVG.

You are attempting to recreate a retained-mode API in an immediate-mode API. Why is ‘use SVG’ not sufficient for this?

Many developers who work for [browser] vendors have simply said that SVG should be used instead of Canvas for interactive applications. The HTML5 editor has repeatedly suggested that interactive elements not be allowed within the Canvas sub-tree. The HTML5 has repeatedly specified that button and checkbox, anchor and radio be the only widget types allowed in the Canvas sub-tree. These specification changes were reverted in respect for W3C procedure. Note, the restriction is still present in the WHATWG specification.

Transparent, but with no interactive content descendants except for a elements, button elements, input elements whose type attribute are in the Checkbox or Radio Button states, and input elements that are buttons.

Use of CSS overlays

Canvas developers rarely use CSS overlays to handle focus management and other interactivity. This is likely because of the difficult management of z-index ordering as well as the manual computation of bounding boxes. This difficulty is avoided with the drawFocusRing method of Canvas 2d, but no vendors currently support the method, and so CSS overlays are the only real-world practice available today (December 2011). There are now multiple proposals for enabling clickable regions through the use of the Canvas sub-tree, DOM events, and new methods to the Canvas Context 2d API. Other participants in the working group have gone forward with attempting to support more complex widget types.

Proposals: 2 simple examples

These proposals, as envisioned can be expressed by two simple examples, both of them forward events into the Canvas sub-tree to bubble up the DOM in standard fashion. ( setDrawingFor proposal ): beginElement(elem1); … drawing operations here … endElement(); This proposal captures paths when fill*() and drawImage calls are made, starting from the time beginElement is called, and binding those paths to the target element in the Canvas sub-tree. (setClickableRegion proposal) beginPath(); … drawing operations here … setClickableRegion(element); Like drawFocusRing, the setClickableRegion proposal only uses the current path in the Canvas state, and binds that path to the target element.

Both of the methods are shown in the context of the input type=checkbox demonstration:Canvas 2d Pointer Checkbox

Other strong disagreements: the W3C and WHATWG specifications remain divided

Outside of this active proposal there exist strong disagreements about text handling, whether it be rich text editing or reporting on the caret position and selection. The group has yet to build wide consensus that Canvas widgets are and will be regular staples of web application deployments. As such, most of the existing demonstrations of Canvas applications have not been accepted as Canvas use cases.  It’s consistent to argue that HTML5 should prohibit the use of “canvas” to create text editors. New developments, such as Mozilla’s PDF.js and the W3C Chair decision to include caret tracking have loosened some of these positions against Canvas-based complex widgets. Still, the WHATWG and W3C specifications remain divided as does the consensus of this working group.

Lack of progress: hindering accessibility

The lack of progress, and the bulk of thread-traffic on this list has been related to a fundamental disagreement about the scope of the Canvas element and the public-canvas-api list. Should Canvas-based ARIA widgets be supported? Complex Canvas-based widgets are being authored. There are many examples on the web today. These examples work, but they are not [generally] programmatically accessible: testing and automation tools as well as assistive technologies are not granted exposure to the values they need to work. This is, at times, a self-imposed limitation of the developer, having used HTML5 Canvas instead of HTML4 and/or SVG. But, these are also limitations imposed by developers who work for vendors, having decided that they will not support Canvas accessibility on principal and in practice.

Where developers have jumped in, head-first, putting money and resources into Canvas-based user interfaces, vendors have a responsibility to their users. Though there are many reasonable arguments as to why authors should use SVG, those arguments do little to support users who are trying to access Canvas-based interfaces. Those users are excluded. The bar is simply set to high for most authors to support them. Several proposals have been put out in order to lower that bar.

There remains a fundamental disagreement about whether or not the problem should be fixed — about whether there is an accessibility problem. At present, there are only minor disagreements in how to fix the problem.

Using nested figure elements is a useful method for grouping related content instances, such as images.

Examples are provided on a separate page: Use of nested figures

Recommended methods – grouped images

Examples of recommended methods for marking up groups of images which have associated captions:

• Example 1- caption text visible by default
  
• Example 2 – hide/show caption text using CSS
  

How NOT TO markup groups of images with associated captions

The HTML5 specification does not currently provide an example of using nested figure elements to mark up a group of images and their captions. Instead it promotes the use of the title attribute anti-pattern to caption the individual images within a figure.

An example of how not to mark up groups of images which have associated captions is provided in Example 3 – bad code example

ARIA landmark support summary data

• Jaws 11/12/13 has complete support.
• ChromeVox has complete support.
• VoiceOver supports all landmarks except “form”.
• NVDA supports all landmarks except “application” and “form”.
• Window Eyes does not support ARIA landmarks.

ARIA landmark support details:

WAI ARIA Landmark Role Tests 21/11/2011

Stating the obvious

Semantics are not just about accessibility, accessibility is not just about assistive technology. But semantic information (name, role, states and properties) carried by HTML elements and attributes is integral to making content on the web accessible, especially for those who rely upon assistive technology to access and interact with web content.
Historically and currently accessibility support for HTML features in browsers lags behind other facets of feature implementation, and unfortunately accessibility support is not taken into account when browsers announce support for a feature. Which is why we get claims about HTML5 structural elements being implemented in browsers. What is actually meant, pretty much, is that visual styling has been implemented.

HTML accessibility support

Where there are clearly defined semantics already available via acccessibility APIs for new HTML5 features, it is easy for browsers to implement the support and no excuse for AT to not understand and convey the appropriate information to users.
The accessibility implementation and semantics of particular HTML5 elements is still being worked out. This is mostly due to the semantics, from an accessibility support perspective, not being well specified or specified at all in the HTML5 specification. The HTML to accessibility API implementation guide is intended to help with this, but it is still in early development

hgroup – an element in search of a cowpath

For example, the hgroup element is a mess. Why? because it is an element in search of a cowpath. As currently specified it does not provide a useful semantic to assistive technology users, in fact it does the opposite, it removes potential information about subheadings/subtitles/taglines etc, by forcing implementers to collapse the subheading semantics into the parent heading. That is why hgroup is at risk in the W3C HTML5 specification, with 5 detailed proposals to either abolish or replace it.

header – useful or not?

Another example is the header element from discussions with browser and AT implementers, it is considered that the header element does not add much value as it does not provide anything that currently available semantics does not. To understand why, it is useful understand the ways in which screen readers can expose HTML element information to users. As a consequence it may well not be implemented in browsers or AT.

HTML5 outline algorithm

In regards to the outline algorithm, Jeremy states “The new outline algorithm in HTML5 will make life a lot easier for future assistive technology” which suggests that he is not aware of the implementation of the outline algorithm in JAWS 12/13, unfortunately the current implementation can actually undermine users ability to navigate and understand document structure. Note, also it does not take hgroup into account.

figure and figcaption – meaning in the pipeline

The figure and figcaption elements currently have no semantic meaning. This is partly because the semantics are not defined in accessibility APIs and partly because the available role semantics and labelling relationships have not yet been implemented in browsers. There is active work going on to change that.  As part of working out how the semantics of these new elements could work I wrote a post about the challenges of defining the semantics. At the W3C TPAC meetings last week we discussed the addition of a figure role in ARIA 1.1. There is also moves afoot to add a figure role to the iAccessible2 API, and Firefox are making progress (Firefox bug) on the implementation of the labelling relationship for figcaption/figure and role implementation for figcaption.

Browsers have an integral part to play in accessibility support

For a long time, the refrain from certain quarters has been, screen readers don’t support feature X its been in HTMLX for ages, F#@King screen reader vendors. They are an easy target. Part of what HTML5Acessibility was set up to do was draw attention to the browser vendors role in providing accessibility support. I suggest that browser implementation is an integral aspect of HTML accessibility support, without it there is not chance of robust, interoperable access to web content for AT users. Take a look at the debacle with longdesc, AT for the most part cannot be relied upon, and should not need to be relied upon to implement accessibility features, without the browsers doing their part.

HTML5 a work in progress, get involved!

HTML5 is still a work in progress, but it’s at a stage now where significant changes must not be handed down from upon high, the community must have the opportunity to be involved in affecting change. Involvement in the W3C HTML working group provides that opportunity, get involved!

Detecting if images are disabled in browsers

I went searching on the internet to find a suitable script for detecting if images are displayed or not. I found this post Use Javascript to detect if images are disabled.The script appears to work fine in Internet Explorer and FireFox, but not in Chrome and Opera ans Safari. It also looked a bit complex for me. What I wanted was a simple method that worked cross browser.

The problem

To be clear, what I am referring to in this case is inline images, though the same method will work with CSS images as long as there is one img element on the page to test. On HTML5Accessibility.com the following pattern is being used, the CSS for which I borrowed from CSS in Action: Invisible Content Just for Screen Reader Users.

HTML

<img src="images/cross.png" width="16" height="16" alt="">
<span class="hidden">Not supported</span>

CSS

span.hidden

{
position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
}

This works great if you have images enabled (the presence of the images are not announced by screen readers due to the use of alt=”" and the text is announced, although it is not on screen), but not if you don’t, because the images are not displayed and the text is still hidden off screen, d’oh!

Major modification 9/11/2011

Thanks to @thierrykoblentz for providing a much simpler method (offsetWidth) to check whether images are enabled/disabled!

Tested in Firefox/Opera/Chrome/IE on windows all work fine!

Try the updated test page in your fave browser/OS.

The noImage() script

function noimage()
{

if (document.getElementById('flag').offsetWidth == 1)

{
var objHead = document.getElementsByTagName('head');
var objCSS = objHead[0].appendChild(document.createElement('link'));
objCSS.rel = 'stylesheet';
objCSS.href = 'alt.css';
objCSS.type = 'text/css';
}

//add to body

<body onload="noimage();checkHC();">
<img id="flag" src="clear.gif" alt="">

What  the script does

It checks the value of the offsetWidth property of a 1 x 1 pixel image added to the top of the page. if the check returns true, images are enabled, if false images are disabled.   If images are enabled  it adds and external style sheet containing the style rules to hide the text off screen.  By default the text and images are visible, so that the text will be visible if users have JavaScript disabled. 

Checking for Windows High Contrast

It also seemed like a good idea to have the text visible when Windows high contrast mode is enabled (shift + alt + print screen keys), so I added the following function (borrowed from the AOL AXS script library), that checks if Windows high contrast mode is enabled. If it is enabled both images and text are displayed.

function checkHC() {

var e,c;
//Create a test div
e=document.createElement("div");
//Set its color style to something unusual
e.style.color="rgb(31,41,59)";
//Attach to body so we can inspect it
document.body.appendChild(e);
//Use standard means if available, otherwise use the IE methods
c=document.defaultView?document.defaultView.getComputedStyle(e,null).color:e.currentStyle.color;
//Delete the test DIV
document.body.removeChild(e);
//get rid of extra spaces in result
c=c.replace(/ /g,"");
//Check if we got back what we set
//If not we are in high contrast mode
if (c!="rgb(31,41,59)"){
return true;
}
}

I then wrapped then wrapped it all together and added it to HTML5Accessibility.com. There is also a test page available. The scripting is by no means elegant, if anybody wants to improve it please do!