If you can’t be bothered to do either of those things, you might instead want to have a quick glance at the things which struck me as interesting…

• The survey had 665 valid responses
• Only 4.7% described themselves as beginners with screen reader technology (but as they point out, we shouldn’t draw inferences from this, because there is no way of knowing if this survey sample is fully representative — which we also need to bear in mind when looking at the other results)
• JAWS is the primary screen reader for most (2/3 of correspondents) but 5 other screen readers have shares over 1% so we can’t assume screen reader = JAWS
• 83% have updated their screen reader in the past year (but if the survey sample is artificially tech-savvy, this might be artificially high also)
• When asked which browser was used with their primary reader, the top four, in order, were IE8, IE7, Firefox 3, then IE6. It’s worth noting that the IE6 percentage is significantly lower than reported by most site analytics, although it’s difficult to tell whether this relates to screen reader requirements or sample selection
• More than 74% of users report that javascript is not disabled in their browser, with almost 15% don’t know. Is javascript still the big bogeyman barrier suggested by WCAG 1.0?
• There’s something very interesting about alt text. I’ve always been working on the assumption — long backed up by other professionals — that screen reader users would prefer to have decorative images to have a null alt text so that they would be ignored by the screen reader. It would instead appear that over 75% would prefer either “smiling lady” or “photo of smiling lady” to indicate such an image (of a smiling lady). Not particularly convinced this result should see a change in best practice however — but I’m open to persuasion if this is what people want…
• The most problematic three items were CAPTCHA (presumably particularly those which are visual-only), Flash, and ambiguous links. Looks like another vote for the end of ‘click here’ as well as a reminder to all those companies who produce inaccessible flash-only versions that they are causing accessibility problems
• …in comparison, lack of ‘skip’ links doesn’t seem to bother many people
• Social media use seems to be (mostly) tied in with perceived accessibility, with the most used social media tool (YouTube) being seen as at least ‘somewhat accessible’ by 78% of people (although not the highest), and the least used (MySpace) reporting the least accessible (assuming that the graph is correct, and not the figures, which were wildly out of whack with the graph at the time I put this together). MySpace, which is least used, is reported as one of the most accessible; some of the most used are reported as the most accessible, so there does not appear to be a direct link between accessibility and use, . This information would be better presented in next years survey as a % difference between screen reader users and users in general — as it would be more possible to draw comparisons as we could see differences in trends: it’s impossible to know to what extent (if any) these percentages are affected by accessibility without knowing the % use in the general population
• In short, there is no “typical” screen reader user.

I don’t really have a problem with the use of acronyms, provided that they are expanded (whether via HTML or in text) on at least their first use in a given page or message. What I do object to however is the assumption that if you use an acronym or abbreviation, other people will understand what you mean, and if not, they can always look it up.

Well, no. If you can’t be bothered to make your message sufficiently clear in the first place, I don’t see why I should bother to dig around trying to figure out what you are trying to say. And sadly, I find that the accessibility community are one of the worst when it comes to this.

The idea of accessibility is to make websites (or other things) more easily usable by people, most frequently specifically “people who are disabled”. This is emphatically not just about using alt tags (note: always call them tags, it annoys the purists). Accessibility is not just about the blind.

If you want to make your sites accessible, you need to consider other impairments: motor impairments — users who can’t use a mouse; hearing impairments; other visual impairments; dyslexia and other cognitive impairments and so on. And he we come to something which is a cross-over between general good practice and accessibility — the ease with which your content can be understood.

Obviously cognitive impairment is not a binary position: it reflects a continuum of impairment. You can understand therefore that if your page is slightly easier to understand, this will tip the balance for some people between being able to use it and not.

And this is where we come to the counter-intuitive a11y abbreviation. It looks like “ally” (and many pronounce it as such), but it means something entirely different. It means “accessibility”. How on earth do you get from “a11y” to “accessibility”, you may well ask. Ahah! Here’s the clever bit (or, in my opinion, the bloody ridiculous bit).

What you do is you look at the number of letters between the first “a” and the final “y”. You’ll find there are 11 of them. So you scoop all of those out and replace them with the number 11. You’ll also see this in i18n and similar. They are the sort of abbreviation which are completely and utterly obscure and opaque to anyone not already “in the know”.

As far as accessibility goes — something which is supposed to promote understanding — the use of a11y is therefore very clearly b6s.

I understand that there is a need sometimes (for example when on twitter) to use an abbreviation, as accessibility is quite a long word. But any abbreviation used should be one from which the word “accessibility” can be reasonably inferred without esoteric knowledge.

One possible suggestion would be to use the abbreviation “access” (6 letters). It’s significantly clearer than “a11y” (4 letters) and significantly shorter than “accessibility” (13 letters). It does have one drawback in that people frequently use “access” (particularly on twitter) to refer to Microsoft Access databases.

So there’s two questions.

1. Do you agree that a11y is a poor abbreviation for accessibility, and we ought to use something better?
2. What should we use instead (and why)?

My personal belief (after having looked around on twitter) is that #access might clash too much with other things, so a different option may be preferable; but also that #access is preferable to #a11y. But can we come up with something that is better than both of them?

I don’t really think we should be looking at something specifically related to the web, as people might want to use an equivalent tag to mark accessibility in other software (or in a non-IT capacity).

So let’s have your thoughts on the following, and any others you can come up with:

• #a11y
• #access
• #accessibility
• #accessy
• #disability
• #disacc
• #webacc

It is mandatory for Government sites to have stats audits:

In the current climate of open, transparent and accountable government, it is now mandatory for government websites to have stats audits.Adam Bailin, Digigov: Benefits of Government Website Auditing

Now there are various different ways to analyse the stats, but in order to identify unique visitors, a lot of stats thingummies will use the storing of cookies. You with me so far?

Now the EU are currently discussing exactly what to do over file-sharing. Part of this telecoms package includes this:

Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his/her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia about the purposes of the processingElectronic communications networks, personal data and the protection of privacy

Note that: in order to store or access a cookie, the user must already have given consent. This is not the same as the current “right to refuse” which means (as I understand it) that you’ve got to include information about what the information is used for and how the user can opt out (such as by having a ‘privacy’ page with this information linked to at the bottom of your site).

Struan from Out-Law.com was fairly clear on what he believes it means. You must provide a notice and give the user the option of giving or declining their consent before setting or accessing a cookie, with only one limited exception:

There is an exception for cookies that are “strictly necessary” to provide a service “explicitly requested” by the user. Consequently, no cookie notices are required to serve a cookie that helps a shopper get from a product page to a checkout; but notices are required for cookies that are used in traffic analysis or advertising.[...]

[...]sites can deliver cookies to a user’s computer only if the user “has given his/her consent, having been provided with clear and comprehensive information” unless, as now, the cookie is “strictly necessary” for a service “explicitly requested”.

European Commissioner Viviane Reding expressed concerns about behavioural advertising this month. “European privacy rules are crystal clear: a person’s information can only be used with their prior consent,” she said.

Out-Law.com: Online advertising is threatened by Europe’s cookie law

So if you want to use cookies for advertising (not a major thing for UK public sector sites at the moment, but people are heading down that road) or use cookies for analytical reasons, you must first give people the opportunity to decline first. That’s an active thing: you must explicitly get their consent (as I understand, for every different cookie, as you’ve got to explain what the information will be used for).

What right to refuse did I get?” our source asks of his own visit to a homepage placing a selection of cookies on his computer. “You might imagine some sort of pop-up: ‘do you refuse this – yes / no’. You could phrase that many ways but it seems to me you need to ask for a reaction before storing or gaining access to a machine.” Can you imagine a pop-up box to explain 30 cookies, or 30 pop-up boxes? [more from] Out-Law.com: Online advertising is threatened by Europe’s cookie law

And of course if you are a public sector site, you need to comply with either WCAG 1.0 or 2.0, so you simply can’t do this. WCAG 1.0 says:

10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]WCAG 1.0

WCAG 2.0 is a teensy bit different. You’re not allowed to cause a “change of context” (new windows, change of focus, change of content of text on the page) unless you have informed the user first. This includes when any component receives focus (such as opening a new page):

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A)WCAG 2.0 Success Criterion 3.2.1

…or when you change anything on the page…

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)WCAG 2.0 Success Criterion 3.2.2

That is, every time you want to set or access a cookie, you’d need to inform the user before you pop up a window (or change the text on the current page) to ask the user if they will allow you to set or access that particular cookie.

So on the one hand you must inform the user what you will use the cookie for — and allow them the chance to withhold permission for it — before you set any cookies; and on the other hand, you can’t have any popups asking about setting cookies unless you’ve already informed the user first.

In other words, every time a user starts a new “visit” to the site (whatever their “landing” page was intended to be) you are going to have to:

• Take them to a page (or series of pages) which explains all the cookies they are likely to encounter on your site and ask their permission to set them (except for cookies essential to the user-initiated process, such as shopping baskets)
• Ensure that these permissions are recorded and stored for the remainder of that visit
• Then take the user to the page that they originally wanted to visit

I can foresee a couple of teensy problems. Firstly, if you don’t do this, you’ll be breaching EU law (?) — assuming the current telecoms bill is passed — or alternatively you can instead choose to breach accessibility requirements. On the other hand, if you do do this, you’re going to massively inconvenience, not to mention severely piss off all of your users.

And of course that’s before we start trying to work out what constitutes a new ‘visit’ for someone who has refused to allow you to set cookies…

So, in line with Struan’s objections, I’d suggest that we hope that (and maybe do what we can to help) the new telecoms bill is not passed…

I’m looking at what parts of WCAG 2.0 that I think are appropriate to set as a minimum standard for public sector sites in the UK. Personally, I think there are three key points that need to be considered.

• Public sector organisations come in a variety of shapes and sizes, and aren’t just Local Authorities and central government departments. Is it appropriate to demand that all public sector sites should have the same level of compliance?
• We need to ensure that all public sector sites achieve a level of accessibility that is achievable and where it is not unreasonable to apply sanctions (of whatever type) if an organisation fails to meet the required level. Currently, too many sites fail to achieve the required standard: is this a problem with the sites, or is it a problem with the standard against which they are measured?
• We need to ensure that public sector sites are not discriminating against people with disabilities: all sites should be required to have at least a basic level of accessibility.

Comparison against WCAG 1.0?

So, taking these three points as my starting criteria, and looking at WCAG 2.0, and comparing it to the previous mandated standard — WCAG 1.0 at the Double-A level — what do I notice?

Firstly, I notice that there are a different number of criteria. To achieve WCAG 1.0 at the most basic level, we need to pass 16 criteria. To achieve the same against WCAG 2.0, we must pass twenty-five. Does this mean WCAG 2.0 is more stringent, and tougher to pass? Well, that’s something we need to consider — although the Double-A level of WCAG 2.0 only has 13 criteria compared to 30 for WCAG 1.0. Could we argue that with 46 tests on one site and 38 on the other, the two are roughly equivalent?

Well no, not really. Unfortunately it’s not as simple as that. WCAG 2.0 represents such a significant culture shift from WCAG 1.0 that in attempting to determine a suitable conformance level it does not make any practical sense to include WCAG 1.0 as a comparison. Instead, we’ve just got to look at WCAG 2.0 and see what we think is appropriate.

Accessibility Supported

The idea of what is an accessibility supported technology could be one of the most problematic features of WCAG 2.0, but — if you’ll indulge me for a moment first — I hope to be able to come up with a relatively simple answer. First, it’s important to remember that you must only rely on accessibility supported technologies:

Accessibility Supported

Using a technology in a way that is accessibility supported means that it works with assistive technologies (AT) and the accessibility features of operating systems, browsers, and other user agents. Technology features can only be relied upon to conform to WCAG 2.0 success criteria if they are used in a way that is “accessibility supported”. Technology features can be used in ways that are not accessibility supported (do not work with assistive technologies, etc.) as long as they are not relied upon to conform to any success criterion

WCAG 2.0

Right. That’s the “quick and simple” definition. Of course, you’ll be wondering what the full explanation looks like, if that’s the quick and simple one. So here is the more complicated bit — how do we determine whether or not a technology counts as accessibility-supported.

To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

1. The way that the Web content technology is used must be supported by users’ assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users’ assistive technology in the human language(s) of the content, AND
2. The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:
   1. The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS); OR
   2. The technology is supported in a widely-distributed plug-in that is also accessibility supported; OR
   3. The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported; OR
   4. The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:
      • does not cost a person with a disability any more than a person without a disability and
      • is as easy to find and obtain for a person with a disability as it is for a person without disabilities

Note 1: The WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported

WCAG 2.0: Accessibility Supported

Right-ho. This bit looks complicated, but let’s break it down. To qualify as an accessibility-supported technology, the technology must be freely available, and either free or the accessibility-supported agents don’t cost more than the standard ones, and that particular use of technology has been tested for accessibility support.

Note also the note: the W3C aren’t going to tell us which technologies count as accessibility supported, this is something we’re going to have to work out on our own. And it will change over time.

So where start? HTML and CSS, obviously. Javascript? We’ll come back to that one. Flash and PDFs? Well, I’d say so: assistive technology can handle these pretty well, just so long as they have been put together in an accessible manner. You can’t just slap it on the web and assume it’s fine. But if you build it properly, it should be.

So that’s HTML, CSS, Flash and PDF I’d allow. What the COI need to do is to state which technologies are appropriate for public sector sites. Someone needs to take on this responsibility for UK public sector sites, and I think the COI is yer man.

Is Javascript Accessibility Supported?

Well, some bits are. And some bits aren’t.

And now I’ll look at Javascript. For Javascript, I’d allow use of particular pieces of javascript, where that particular script/command has been checked and documented as being accessible. For this, I think it would be useful for someone (the COI again?) to keep a list of javascript commands and techniques which have been found to work with assistive technologies: if someone wants to do the testing for an additional bit, and make their documentation available to the COI, then it gets added.

I think the time has come to accept that Javascript does not necessarily make a site inaccessible, and that sites can rely on javascript and still meet accessibility requirements — provided that script has been tested as being accessible. The most obvious example of this for me is that javascript which is ubiquitous within .NET sites — the javascript postback.

When working for a Local Authority, I ended up in a discussion with Microsoft about this who seemed quite content that this technology was accessible (and my test case, which I got screen reader users to look at, seemed to confirm this), but that obviously Local Authorities couldn’t use it, because under the current rules they were not allowed to rely on javascript — despite this javascript being tested and accessible.

This is obviously nonsense. Which is why I think we need to take a more complex view with javascript: let’s record accessible uses of javascript, and then people can use these. If they want to use something not already recorded, they have to carry out the testing and prove that it’s accessible.

Conformance Claims

…are optional, but if you do want to include them, they need to be made in a very specific way. This is not a case of sticking one of those accessibility badges on your site. You’ve got to provide much more information than this. Indeed, if you do venture to stick an accessibility badge on your page then this is deemed a conformance claim, and it must be accompanied by all the other necessary information.

So I’d suggest that public sector organisations are discouraged from including conformance claims. If they want to include some sort of information, a description of what testing they have carried out (and who with) may be may appropriate, but I tend to think this sort of thing is of no benefit — it’s self congratulatory backslapping only: describing what you’ve done does not in itself make the site more accessible, and you ought to be doing it because it’s right, not because you want to claim some credit for it and feel smug or superior.

Success Criteria: Perceivable

Criteria in this section:

• Provide an equivalent text alternative for non-text content (Level A)
• Provide an alternative for pre-recorded audio or video except where the media is a media alternative to text. If the media is time-based, the time information must be associated with it.(Level A)
• Provide captions for pre-recorded audio, except where the audio is a media alternative to text (Level A)
• An alternative for time-based media or audio description of prerecorded video is provided for synchronized media, except when the media is a media alternative for text and is labeled as such (Level A)
• Information, structure, and relationships conveyed through presentation can be programmatically determined (use headers, lists and so on properly) (Level A)
• When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined (Level A)
• Instructions provided for understanding and operating content do not rely solely on sensory characteristics (don’t say “fill in the fields with a circle next to them”, “put your answer in the box to the left only”) (Level A)
• Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)
• If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)
• Captions are provided for all live audio content (Level AA)
• Audio description is provided for all prerecorded video content in synchronized media (Level AA)
• The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 (except logos, decoration etc) (Level AA)
• Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality (Level AA)
• If text can be used to supply the visual presentation of the information, text is used to supply the information, unless it’s essential to be presented in a particular way (e.g. a logo) or the image can be customised by the user (Level AA)

All perfectly reasonable (bar maybe one, but I’ll come to that). I’m also delighted to see that you can’t have constant jangling background audio (not that you tend to find that in the public sector, but it’s a personal bugbear of mine).

This “media alternative” is a key thing in this. Initially, these success criteria seem a little onerous: thou must providest captions and so on, but that isn’t really the case at all. The media alternative specifies that where the media provides no more information than is available in a standard text equivalent (transcript or so on), then that text equivalent is fine. So in many cases, you don’t need captions, audio descriptions or so on, provided that you have supplied a good enough text alternative to the media.

As regards level AA, I tend to think that if you’re sophisticated enough to have live streaming audio content, you ought to be sophisticated enough to put captions on it. This does however mean that you need to be careful when you’re considering putting video conferencing, or live council debates on your website — you have to have someone sticking captions on it.

The potential fly in the ointment is the second Double-A one: success criterion 1.2.5. This requires that any public sector organisation must provide audio description of video content even if all of the information that can be obtained from that video is also supplied in a text alternative.

I have to be totally honest here and accept that while having the information in text format is probably not quite as good as an audio equivalent, I feel that this puts an overly onerous burden on public sector sites to little practical benefit: the early success criterion demands that the text alternative contain all of the information in the video, and I would have thought that this should be sufficient.

For me, the accessibility standard ought to be set at a level where someone with a disability can carry out all of the tasks, and access all of the information on a site, but not at a level that requires public sector organisations to undertake specifically complex work for little benefit. The standard ought to be achievable and it ought to be reasonable. And for that reason, I would recommend that the COI do not include success criterion 1.2.5 as part of a level that is mandatory for public sector sites.

Other than this, I think the rest of the perceivability success criteria are perfectly reasonable and appropriate.

Success Criteria: Operable

And the operability criteria:

• All functionality of the content is operable through a keyboard interface (Level A)
• If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface (no keyboard trap) (Level A)
• For each time limit that is set by the content, it is either adjustable, extendable, switch-offable, essential to the activity, over 20 hours, or related to a real-time event (Level A)
• Moving, blinking, or auto-updating information that starts automatically can be stopped, paused, or otherwise adjusted (Level A)
• Pages do not contain anything that flashes more than three times in any one second, or flash below the general flash and red flash threshold (Level A)
• Provide a mechanism to skip navigation and similar repeated blocks (Level A)
• Use meaningful page titles (Level A)
• Focus order follows in a meaningful manner (Level A)
• The purpose of each link can be determined from the link plus surrounding context except where the purpose of the link is intended to be ambiguous to users in general. Like this one. (Level A)
• More than one way is available to locate a page except where it is the result of, or a step in, a process (i.e. provide navigation, search, site maps etc) (Level AA)
• Headings and labels describe topic or purpose (Level AA)
• Make the keyboard focus indicator is visible (in other words, use :active and :focus pseudoclasses as well as :hover) (Level AA)

“Public sector websites shouldn’t cause seizures” seems perfectly reasonable to me, as do the other criteria. I can’t see any reason why any public sector site should not be expected to achieve all of these things. Most of them are done anyway, and the ones which are not already standard across the public sector ought to be standard across the public sector.

The whole lot of these ought to be mandatory. None of them are difficult to achieve, all of them will impact on people with disabilities, there’s simply no excuse for non-compliance with this lot.

Success Criteria: Understandable

And the success criteria here…

• The default human language of each page can be programmatically determined. (Level A)
• When any component receives focus, it does not initiate a change of context. (Level A)
• Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component (Level A)
• If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)
• Labels or instructions are provided when content requires user input. (Level A)
• The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular (Level AA)
• Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated (Level AA)
• Components that have the same functionality within a set of pages are identified consistently (Level AA)
• If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)
• For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)
  • Submissions are reversible
  • Data entered by the user is checked for input errors and the user is provided an opportunity to correct them
  • A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission

There are a couple of things here which are worthy of note: I’ll skip over language as that’s easy enough to apply using the lang attribute or xml:lang depending on what and where you’re doing it, so instead I’ll stop at change of context. By this, it means that you shouldn’t change the on-screen content or send someone off to a new page unless they click a link or button or you’ve already told them this will happen.

A common example of this is drop-down lists which, upon selecting an option, immediately take you off to that selected option. The obvious problem with this is that if you’re using a screenreader, you may not know this is going to happen. For example, on the Redbridge i council site, if you change the drop-down selection in ‘view events of type’, it will automatically change the selection of events viewed underneath. This is done in a keyboard-accessible manner (it does change as you scroll through the list, which is a good start!) but obviously there is no on-screen warning that this will happen.

Again, it’s an easy enough fix: either provide specific instruction on what will happen, or add a submit type button.

Beyond this, the requirements are again fairly simple: provide meaningful error messages, give as much detail about the error as possible, and there’s also the key bit about submitting a page which performs some sort of update action. This is likely to be majorly beneficial to most users — it gives you a bit more confidence if you can double-check your details before you submit them — and is really not that difficult to achieve.

Again, there’s no real excuse for any public sector organisation not being able to hit these checkpoints. They don’t require anything special to achieve; they’ll benefit a wide variety of users and they should be considered good practice anyway.

Success Criteria: Robust

This is almost a little rump section: there’s not a great deal to it, as there are only two success criteria here…

• Markup parses successfully: elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique (Level A)
• For all user interface components the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A). This success criterion is primarily for authors who script their own components. Standard HTML controls already meet this success criterion when used according to specification.

As regards the second one, if you’re using HTML controls in the standard manner, you’re fine already. As regards the first, parsing isn’t exactly the same as validation — but anything which is valid HTML must parse ok. And as public sector organisations were previously expected to have valid code, successfully parsing code should already be in place.

Again, there’s no reason why any public sector sites shouldn’t be able to comply with these without any problem.

Success Criteria: Triple-A

So far, we’ve just looked at Single-A and Double-A success criteria, but are there also any Triple-A success criteria which we should expect to be mandatory for public sector sites?

No. There are a lot of different success criteria at the AAA level which would be useful to certain groups of people with disabilities, but these will generally only impact on smaller groups of users, will only be relevant in certain circumstances, or will add additional accessibility beyond the basic requirement.

For these reasons, I’d suggest that public sector organisations are encouraged to comply with as many of the AAA success criteria as is feasible for them to do so, but that these should not be mandatory.

However, there are certain things that I would particularly recommend, which I think are fairly easy to achieve and will generate real, practical benefit:

• Do not justify text
• Provide information about the users location within a set of pages (menus, breadcrumbs etc)
• Use section headings to organise the content
• Provide mechanisms for identifying unusual words, jargon, acronyms or abbreviations
• Use simple, plain English

In Summary, Then…

Other than 1.2.5 (provide audio description, irrespective of whether or not text equivalent is available), there are no success criteria at either level A or level AA which appear to be particularly difficult or unreasonable to expect them to be achieved. On this basis, I don’t feel that there is any need for different ‘levels’ of requirement depending upon the size of, or the resources available to, a specific public sector organisation.

I would therefore recommend that the COI set the required conformance level for WCAG 2.0 to be at the WCAG 2.0 Double-A level with the sole exception of 1.2.5, which I think may be unreasonable for some public sector organisations to achieve (this would still require equivalent text to be available with all of the information contained in the video, but it wouldn’t require a separate video with audio descriptions added). I think this would be a very reasonable, practical level of accessibility to expect, one which ought to be achievable for all public sector organisations, and one which should ensure that anyone who is disabled still has access to all of the information and functions provided.

I would be worried that any standard which required conformance against 1.2.5 would either see public sector sites ignoring the accessibility standard, or would see public sector sites simply choosing not to use video and multimedia, which is why I believe this, and this alone, needs to be removed from the requirement before we can set the rest of WCAG 2.0 at the Double-A level to be mandatory for the public sector.

I’d also recommend that the COI encourage compliance with Triple-A level success criteria, and in particular the ones I have listed above which I feel will provide the most benefit with the least effort, but let’s keep it simple, and just make these advisory only.

Having quite a bit of knowledge of accessible web design and in testing against it (feel free to contact me if you want a quote for a site audit, with recommendations for fixes, by the way!), I understand how difficult it is to achieve the triple-A level of accessibility conformance level for WCAG using either version 1.0 (1999) or version 2.0 (2008). I also know that “out-of-the-box” accessibility is impossible: you simply cannot achieve it unless your content editors also know and understand accessibility requirements.

Which was why I was more than a little surprised to see this tweet:

Redbridge AAA-rated for accessibility at the moment, built into the CMS. Immediacy, used by BBC for their Intranet. #digieng@72prufocks

My first reactions were “triple-A? bet it isn’t” and “built into the CMS? now I’m really convinced they don’t understand accessibility”. So, given that Redbridge i seems to be frequently lauded as an example of what local government should be doing, I thought I’d better take a look to see if it is accessible, or if it is likely to present any significant barriers to disabled users.

Whilst not proving the site inaccessible, the fact that the home page failed to validate was probably not a good start for a site which was allegedly claiming triple-A compliance, as it knocks that out of the water straight away…

And the short answer is that it isn’t accessible. Never mind the triple-A level of compliance, it fails to meet the single-A level of compliance for either WCAG 1.0 or WCAG 2.0. And of course if you’re not achieving even the single-A level of conformance:

A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document.WCAG 1.0: Priorities

I wouldn’t normally be quite so public about this criticism, but for the fact that Redbridge i appear to be claiming a conformance level they come nowhere near achieving, and for the fact it appears to be frequently held up as an exemplar of what public sector sites should be doing when it is in fact failing the disabled, and it is failing them badly.

It wasn’t even that I had to look far to find problems with Redbridge i. I managed to find enough failures on the home page alone to demonstrate that it does not achieve any WCAG conformance levels. Rather than go through every checkpoint and success criterion though, and the site in great detail (I’m not being paid to do that), I will instead walk you through how Redbridge fails different groups of users — and the checkpoint references appropriate, if you’d like to read on, Macduff…

Redbridge Fails: Visually Impaired Users

Firstly, there are visually impaired users. Now Redbridge does offer some useful things here: the accessibility page offers the user the chance to change the text size across (most of) the site, and to change the screen colours. This is a good thing, and it is something that is certainly not offered as standard across Local Authorities. Redbridge deserve credit for this.

But good intentions only go so far if they are not carried out well. For a start, Redbridge i is very script-heavy. I haven’t gone to the trouble to check whether every single piece of javascript works with every piece of assistive technology, which would mean that practically, and as far as WCAG 2.0 is concerned, this is okay. But if Redbridge want to claim conformance against WCAG 1.0, they need to ensure all functions (or equivalent functions) also work without javascript. And this is not the case.

Here’s an example of the Redbridge Jobs section, surely one of the most important parts of any Local Authority site. Assuming you have javascript enabled, you need simply change the value in the drop-down box, and it will pick up the jobs of this type automatically. Fantastic, eh?

Er, well, no actually. Here we’ve got a failure against WCAG 2.0, at level A — the most basic conformance level — on the homepage itself. Now, being an accessibility sort of a person, finding a level-A failure on the homepage of a site which apparently claims triple-A is not what I would call a good sign.

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A) WCAG 2.0: On Input

If you go around changing the content on the page without warning the user that you are going to do so when they don’t do something where they would expect a change of content (button-click or following a link), this is likely to cause problems. So there’s a level A failure at WCAG 2.0 on the home page.

Aha, but what if they aren’t measuring against WCAG 2.0, I hear you ask. Surely as the COI have just recently announced the public sector can now use WCAG 2.0 as a yardstick, the conformance was probably measured against WCAG 1.0?

Don’t worry: it fails that as well. If you don’t have javascript, the little jobs section provides no mechanism by which you can filter jobs by category. Which is obviously in breach of the Priority 1 checkpoint 6.3:

Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.WCAG 1.0 Checkpoint 6.3

Without javascript, you cannot use this dropdown box to filter by category. It is useless. And to me, this demonstrates a great lack of awareness about what is actually required for accessibility. There is one simple thing that could be used to fix both the WCAG 1.0 problem and the WCAG 2.0 problem. And that is to use a submit button to update the data. It’s hardly rocket science. And, they could possibly drop some of the “browser does not support script” messages which appear all over the site while they’re on.

So there we have it: one simple problem that highlights the fact that Redbridge does not properly get accessibility, and fails both WCAG 1.0 and 2.0 at the most basic priority levels. But of course that’s not all…

There’s data tables not marked up properly:

This is actually quite a common error: people realise that the top row of a data table contains header information, so they mark this up accordingly using <th> cells. But they forget that generally at least one item in each row is the header for that row also.

Take the sixth <td> cell in the table. It contains the value “full-time”, which is associated with the header “hours”. Unfortunately, this is not actually associated with any other value, when in practice it would be more useful if the data value in the first column “accountant” was marked up as a header for that row, because then someone would actually be able to ascertain which jobs were full-time…

This fails WCAG 1.0 at the single-A level — and let’s face it, the checkpoint does specifically mention row headers:

5.1 For data tables, identify row and column headers. [Priority 1] WCAG 1.0: Table Headers

…and similarly it fails WCAG 2.0 at the first priority level…

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A) WCAG 2.0: Info and Relationships

Oh, and don’t get me on to poor use of alt text. Decorative images with pointless alt text all over the shop. #FailFailFail.

Redbridge Fails: Mobility Impaired Users

Frequently, people with upper limb disability (or some other problem, such as Parkinsons) will struggle to use a mouse. So they will navigate through a site using the keyboard only. So one of the useful things brought in by WCAG 2.0 (but in place before that at sites where people properly “get” accessibility) is keyboard focus.

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)WCAG 2.0 Focus Visible

Basically, if you hover the mouse over a link on Redbridge i, the link will change in some way (the navigation gets a little blue glow behind it; the underline on some links disappear and so on). If you repeat with the TAB key to move to the same place using the keyboard, you will find, at best, a very faint focus indicator put in by your browser because those designing the site have not thought to include equivalent :focus or :active pseudoclasses in the styling.

WCAG 1.0 fails to address keyboard only users as effectively, so there’s no outright failure of WCAG 1.0 here, but in terms of practical accessibility and also WCAG 2.0, this is a problem.

Redbridge Fails: Hearing Disability

Let’s take checkpoint 1.4 from WCAG 1.0:

For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1]WCAG 1.0: Synchronize Equivalents

For a movie, captions must be synchronised with the presentation. Okay? And that’s Priority 1 in WCAG 1.0, and er… let’s see … exactly the same in WCAG 2.0:

1.2.2 Captions (Prerecorded): Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A)WCAG 2.0: Captions (Prerecorded)

So if there’s a video with meaningful audio (as opposed to some background music), then it should have captions for either WCAG 1.0 or WCAG 2.0 for even the most basic conformance claim. But if you look at the Redbridge Trading Standards Video, it doesn’t have captions, so that’s a conformance fail for WCAG 1.0 and WCAG 2.0.

When I first started looking at this, I thought this was just a technical fail: that it would fail to meet the conformance criteria, but not actually fail people in terms of practical accessibility, because they have produced a transcript of the video. And, had that actually been the case, I would have given them credit for doing more than most Local Authorities actually do.

Only they’ve demonstrated a critical lack of accessibility awareness by missing out help for anyone with hearing impairments. For anyone with vision impairments, the “transcript” is fine: it contains a text equivalents of the images of text which appear on the screen. For anyone with hearing impairments however, it is useless — it contains the text showing the details they will have already been able to see, but there is no way of accessing the information that they have been unable to hear.

May I therefore suggest that as well as remembering that accessibility isn’t just about the blind, the people behind Redbridge actually look up the definition of the word transcript, because all the ones I could find specifically mention that it is a text equivalent of recorded speech, which seems to be the rather important bit they have missed out of theirs…

Redbridge: Built Into the CMS Fail

You cannot have a Content Management System that produces accessible output automatically. The best that it is possible to manage is a system that is capable of producing accessible output, providing your content editors use it correctly. And in order to achieve that, your content editors must have at least a basic understanding of accessibility (or at least that they have to use the CMS in a particular way).

If they don’t, you get #Fail.

For example, in order to achieve WCAG 1.0 at level AA or above, any direct quotation must be marked up with quotation markup — <blockquote> or <q>. Whether or not I think this is actually necessary is another matter: if you say you conform, you need to do it:

Your content editors must therefore know that any direct quotation must be marked up. And the CMS you are using must have the facility to allow them to do this. Otherwise you can’t reach WCAG 1.0 at the Double-A level. (Redbridge failed this on the You Can Make a Difference news page).

Then you’ve got the PDF minutes of council meetings in breach of WCAG 1.0 checkpoint 11.1, which tells you to use W3C technologies if they are appropriate for a task (and there’s certainly nothing in those plain-text minutes which required them to be PDF rather than HTML).

You also need to ensure that anyone adding a list of items knows not only that they need to be marked up as a list, but how to achieve that, and similarly that headers should be marked up appropriately rather than just being deemed headers by the fact the font is put in bold. I have to say actually that Redbridge i did achieve these last two things pretty well so far as I can tell (given an hour to scan the site) but this does not detract from the point that this is not CMS-out-of-the-box, this is content editors who know what they are doing.

Redbridge Terms and Conditions

On a slight aside, I did attempt to read Redbridge’s Terms and Conditions before using the site, only to discover that they didn’t actually seem to make sense.

By using or accessing any part of the Council’s website you agree to be bound by the following terms and conditions:

• By using Redbridge i you agree to be legally bound by these terms, which shall take effect immediately on your first use of Redbridge i. If you do not agree to be legally bound by all the following terms please do not access and/or use Redbridge i.
• The Council may change these terms at any time by posting changes online. Please review these terms regularly to ensure you are aware of any changes made by the Council. Your continued use of Redbridge i after changes are posted means you agree to be legally bound by these terms as updated and/or amended.
• If any of the following terms and conditions is illegal, invalid or unenforceable this will not affect the validity or enforceability of the remaining terms and conditions
• The relationship between you and the London Borough of Redbridge will be governed by English law. You agree to submit all disputes to the jurisdiction of the English courts.

Redbridge Terms and Conditions

In other words, the terms and conditions are that I must obey the terms and conditions, in so far as they are valid in English law. Seems a bit, well… circular to me….

Redbridge: A Model for the future

I am not trying to imply that Redbridge i is crap: it isn’t. In terms of interactivity it is indeed leading the way in showing councils what they should be doing. I do not wish to imply that Redbridge is not something sites should not strive towards in terms of allowing user customisation — allowing users to have the site displaying the information they want, rather than what the council is telling ‘em they want.

That’s all good stuff.

But it does have accessibility issues, and these need to be mentioned for a few reasons.

• If people are holding this site up as an example of what councils should do, they ought to know where the site doesn’t do so well, so they know how they can improve on it
• So Redbridge i can improve on it themselves and truly make their site a shining example of council sites
• If people are thinking that they have achieved WCAG-AAA compliance, or that level of compliance can be achieved ‘out-of-the-box’ with any software, they need to be educated otherwise.
• Those claiming particularly high levels of accessibility conformance need to be held up to scrutiny: otherwise people will follow them and may unwittingly copy bad practice.

So to all those at Redbridge i who’ve read this, and feel like I’ve given them a kicking, I’m sorry. Yes, I know my site isn’t perfect either (but I don’t claim to be, and I don’t have your resources). But rather than give me a kicking, find out who it was who claimed that your site was Triple-A accessible, and shout at them. They are the ones who put you up there to be challenged and knocked down.

But rather than get grumpy about it, why not look to fix the problems, and truly turn Redbridge i into that shining star?

*Ahem*. Now comes the blatant plug bit. if anyone would like me to advise them on what they can do to improve their site — public sector or otherwise — get in touch, let me know what you’re after and I’ll sort you out with a quote.

Information Society and Media Commissioner Viviane Reding has for the first time talked of a ‘European Disability Act’ that could compel EU nations to adopt web accessibility rules together so that all of Europe’s websites become accessible at the same rate.Out-Law.com: European Commission floats idea of web accessibility legislation

As indicated by the headline, we shouldn’t take this to mean that some pan-European accessibility legislation is going to be brought in imminently, but rather that the EU is taking seriously the problems of web accessibility faced by disabled users and is looking to shift to have a more consistent and coherent approach across the EU in order to prevent sites discriminating against, and in some cases effectively locking out those with disabilities.

The UK already has the Disability Discrimination Act which relates to this sort of thing (which I’ve covered before) which impacts both the public and private sectors; the EU already have the 2006 Riga Declaration on e-inclusion which basically states that public sector websites must achieve an appropriate level of conformance, and now we’ve got the potential of something else.

It’s also noteworthy that specific mention is made of the new accessibility guidelines, showing that there is an understanding that the new guidelines (published December 2008) are significantly better than WCAG 1.0 which dates back to 1999. This, together with the COI‘s acceptance of WCAG 2.0 as a standard for the UK public sector shows that the time has come for WCAG 2.0: it’s no longer something we should just be thinking about, we should be using it now.

We should in my view encourage the European-wide adoption of the global web accessibility standard, the new Web Content Accessibility Guidelines. We should do it together and in step so that the online services industry can reap economies of scale and the users get a decent and reliable framework. I believe the way we should do this is to develop together with stakeholders a European Disability Act.Viviane Reding speech

It’s really a shame that there needs to be such an accessibility stick with which to beat people to force them to make their sites accessible to disabled users. If you don’t care whether or not your site is accessible to people with disabilities, then in my eyes, you’re a bit of a poor excuse for a human being. And if you’re a web designer who doesn’t include accessibility as standard in web design, then you shouldn’t claim that you’re a professional.

After all, this is supposed to be the 21st Century, and it’s not even as if accessibility is hard to achieve when properly built into a site in the first place (and even if it needs to be shoe-horned into a site once developed, it’s generally possible to make quite significant improvements without too much pain). But the idea that any individual, company, or organisation can be allowed to get away with producing websites which do not satisfy basic accessibility requirements is disgraceful.

It is discriminating against groups in society for no good reason. It’s the equivalent of sticking a sign on the front of your site saying “no blacks”. If you think that sort of overt discrimination on the grounds of race is wrong, then it’s time to stop tolerating it on the grounds of disability.

Full details, including booking instructions and so on, are available on the event page at PSF’s site. It looks like we may also be running a second version of this event at some point in December in Wales, so if you can’t make it to Birmingham, then by all means contact me or Nick and let us know about your interest and we’ll keep you informed if and when we run the event elsewhere.

There will be five basic sections to the event:

1. Introduction to WCAG 2.0 and background of development history
2. Transitioning from WCAG 1.0 to WCAG 2.0
3. Beyond WCAG — Practical Accessibility
4. Accessibility Testing
5. Accessibility and Social Media

…although obviously if people have specific questions or issues about something not covered by one of the topics above, I will do my best to answer them as well!

The event is designed with the public sector in mind, particularly since the recent COI blog post indicated that they are happy for the accessibility of public sector sites to be measured against the WCAG 2.0 yardstick now, and at some future point (after a transitional period), measurement against WCAG 1.0 will no longer be an option.

So why not book up, come along, and I’ll talk to you about it…

There. How’s that for a hard sell? If you want to give me your opinion on whether or not this was a hard sell, why not book up for the event, come along, and I’ll talk to you about that as well

[NB If you're from the private sector and would like to come along, I'm sure 'tis possible to arrange, but you'd need to speak with Nick first]

To this end, I’ve knocked together a little excel spreadsheet to be used for recording Accessibility Audit Results. It has been designed more specifically for the UK public sector, who are generally required to comply with either WCAG 1.0 or 2.0 at the Double-A level of conformance.

The spreadsheet therefore allows you to record results against WCAG 1.0 or 2.0 for up to 25 pages for all checkpoints and success criteria up to and including the Double-A level of conformance. The abbreviated text for each checkpoint/success criterion links to the appropriate WCAG document to provide further information where required. Please note that at present, the triple-A conformance level details have not been included at this stage as these are not usually mandatory for public sector sites.

The spreadsheet requires you to input “PASS”, “n/a” or “FAIL” for the checkpoints/success criteria against which each page is measured. You may include additional text after this, but each cell should begin with one of these three values if you wish the conditional format colour coding and automatic calculation of compliance levels. The document is available under a Creative Commons Attribution Share-Alike licence, so you are free to make other works from it as you see fit, so long as the original attribution text is retained. I would also appreciate it if you could drop me a line to let me know what you have done with it, but this is not mandatory.

So, fill yer boots. Here’s the Accessibility Test Log (XLS, 99kb)

Of course, we didn’t get things all our own way: one of the things we wanted back then was for the COI to consider the use of WCAG 2.0, which was then in Last Call Working Draft. The COI responded saying that because it had not made its way through to the W3C Recommendation status, they could not at this stage include it in the document, but because they appreciated that it was clearly an improvement on WCAG 1.0, they indicated that they would review the guidance once WCAG 2.0 reached the formal ‘recommendation’ status.

Accordingly, the Delivering Inclusive Websites document said:

At the time of writing, version 1.0 of the Web Content Accessibility Guidelines is the current standard for web accessibility. At such time that version 2.0 becomes a W3C Recommendation, this policy will be reviewed within six months. Consideration will be given to the adoption of version 2.0 as the minimum standard for public sector websites.Delivering Inclusive Websites: Minimum Standard of Accessibility

Fair enough.

And then of course a few months later, WCAG 2.0 made it to become a W3C Recommendation status in December 2008. By my reckoning, this means that we could expect to see some movement and the idea of a review from the COI in mid-2009.

And so, on September 8th 2009, I contacted the COI to ask what exactly was going on — were they reviewing it, or what? And so, again on September 8th 2009, Adam Bailin at the COI published on the Digigov Blog (which I had somehow missed up to this point) a post entitled Web Accessibility: Roadmap to WCAG 2.0.

I don’t know whether this was prompted by my email, or it was entirely coincidental that my email arrived on that day (perhaps Adam can tell us?) but the order of events doesn’t really matter. What is important is what is happening.

And what is happening is that Adam and the COI want us to contribute our thoughts and ideas about how we (“we” being the UK public sector, which I’m lumping myself in with — you don’t get rid of me that easily) should look to transition our standards from pointing at the somewhat dated and less useful but much-better known WCAG 1.0 to the new, whizzo, but less well known WCAG 2.0.

And what he has to say already came as something of a surprise.

Well, assuming that we want the transition to be as smooth as possible, a first step would be to update the current policy to allow conformance with version 1.0 Level AA or the version 2.0 equivalent. This is the current working position that we have been advising departments unofficially. Allowing a choice of standards for a period of time seems like a fair stance to takeWeb Accessibility: Roadmap to WCAG 2.0

Now this is a good surprise. Basically what Adam is saying is that if you are a public sector organisation, and you want to use the new, better WCAG 2.0 standard instead of WCAG 1.0, go ahead and do it now. Fill yer boots. Over time, other people will eventually be required to shift to WCAG 2.0, but for the time being you can basically pick which set of guidelines you’d rather use.

And that’s a good idea. And so are the rest of them:

1. Accurately define conformance criteria for 2.0 that are as close to the current target as possible
2. During the transitional period, allow site owners to choose either version
3. Re-assess conformance requirements for 2.0 and implement a timetable for moving to the appropriate conformance level
4. Put deadlines in place for a 2.0 only system

And he’s after feedback. So why not pop over there and provide some. I’ve already made one suggestion — that half-way through the ‘transitional period’, any new sites going live should be required to conform to WCAG 2.0 (after all, we don’t want new sites using old guidelines) — and once I’ve been through the WCAG 1.0 and 2.0 documentation in more detail, I’ll be making some others. So stay tuned…

Designing Your Implementation

There is then some more technical detail on how specifically to design your implementation, based upon whether the controls you are using are provided by the framework — in which case use the framework’s guidelines to make them accessible — or whether they aren’t, in which case you must develop a native solution for them.

The obvious solution for developers therefore is to use controls provided by the framework wherever possible — not only will you be using controls where the accessibility implementations of them has already been tested, but you’ll be saving yourself quite a bit of development work!

Testing and Delivery

Next we come to how to test whether your non-web application is going to be accessible. For me, this is the really important bit. Again, there are significant similarities to web accessibility testing…

[testing] can be done through a combination of software test tools, manual testing, and user scenario testing with assistive technology (AT) devices [...] Programmatic access and keyboard access are two critical requirements for accessibility. Without them, many different users of AT (such as screen reader and on-screen keyboard users) would be affected and would not be able to use your product at all.Engineering for Accessibility

There are manual tools which can be used to quickly check the UI’s structure and properties, and see what would be exposed to assistive technology. This is where you get to Microsoft’s toolkit which allows you to inspect objects for accessibility. The first thing you want to do is get yourself a copy of the Active Accessibility 2.0 SDK Tools

There are three tools here that you want: Accessible Event Watcher, Accessible Explorer, and Inspect. Inspect works as a little popup window on your screen which gives you all sorts of information about the currently selected control — name, value, description, state, keyboard shortcut and so on. This is ideal as a quick reference alongside any form of windows application to ensure that the correct details are being exposed to assistive technologies.

Microsoft make a point of, er… pointing out that no single tool can verify something is completely accessible, you need to use a combination of tools and testing in order to make sure your applications are accessible. They also suggest you look at UIA Verify which enables you to:

…quickly find and select any UI element anywhere on the desktop. Based on the specific control type and the supported control patterns, UIA Verify provides the built-in test scenarios prioritized for the particular UI element. Developers can add additional test scenarios by adding the code to the UIA Test Library. The tool can output the test results or the summary in various forms.UIA Verify documentation

Of course, the thing to remember for all these sorts of testing tools — and obviously Microsoft don’t fall into this trap — is that while they can highlight potential problems, that does not mean something is definitely a problem, and they are also capable of missing potential problems, so they need to be used as part of an overall testing strategy.

7 Steps to a Better Computing World

Microsoft finish up by raising seven steps for incorporating accessibility into system design. I’m going to amend these slightly to give you all the benefit of my personal opinions instead…

1. Decide if accessibility is an important aspect to your software It is. Move on.
2. Use standard controls as much as possible
3. Design a logical hierarchy
4. Design basic accessibility into your product (keyboard navigation, high contrast testing)
5. Implement your design using the Microsoft Accessibility Developer Center and any other relevant resources
6. Test
7. Deliver your solution and document the accessibility bits