The future of WCAG – maximising its strengths not its weaknesses

2012 was a year of real ups and downs for the de-facto Standards for web accessibility, WCAG 2.0:

WCAG 2.0 is an amazing achievement – establishing a set of guidelines that detail most of the things that website developers and designers need to do to make their websites accessible, and getting them accepted as an international Standard, is a great contribution to digital inclusion globally.

It’s a key piece of the web accessibility puzzle.

However, I don’t believe it’s the full solution for making sites work for disabled and elderly people.

And I believe this message is getting lost in the growing march to harmonise accessibility standards globally, which at the moment is all about removing any national accessibility standards and replacing them with WCAG 2.0.

the ups and downsSo, for 2013, I thought it was time to summarise WCAG 2.0’s strengths and weaknesses, what strengths other national standards have that it may lack, and what will be needed to make it a much better ‘harmonised Standard’ for the future.

Here’s a menu of the aspects of WCAG 2.0 that we’re going to consider:

Strengths and weaknesses of having harmonised accessibility Standards

I’d agree with the W3C that there are many benefits that can be achieved by harmonization of accessibility Standards globally:

“Formal approval by JTC 1 of WCAG 2.0 will increase deployment, reduce fragmentation, and provide all users with greater interoperability on the web.” (W3C)

“Such recognition is expected to increase internationally harmonized uptake of WCAG 2.0 by governments, business, and the broader Web community.” (Jeff Jaffe, W3C CEO)

“We also expect that ISO/IEC recognition will encourage greater convergence around WCAG 2.0, further driving development of supporting tools and software.” (Karen Higginbottom, Chair of ISO/IEC JTC 1)

The claims that harmonizing around WCAG 2.0 is likely to increase WCAG 2.0’s current poor uptake – addressing one of the critiques in Power et al’s research paper earlier this year – are well founded. And this will allow WAI to make more progress in their ‘carrot and stick’ work to encourage adoption:

  • governments globally will be more able easily to place WCAG 2.0 in legislation;
  • more uptake may allow WAI to provide more business cases of the benefits of accessibility to organisations– so far they have only managed to persuade a few to quote any ROI figures (although the OneVoice report in the UK is another useful source of case studies)

But the most important question that seems to have been glossed over is: what affect will that have on the accessibility of websites worldwide?

Because none of their quotes claim that making WCAG 2.0 an International Standard will actually improve disabled & elderly people’s experience of using websites worldwide, that WCAG 2.0 are the right (or only) Standards that should be harmonised around, or that wiping out existing non-WCAG Standards won’t also involve losing useful insights.

So is WCAG 2.0 a great set of guidelines to harmonise around?

Strengths and weaknesses of WCAG 2.0 success criteria

checkpoint sign

In general, each of WCAG 2.0’s individual success criterion is very useful.

From my experience of using them with website creation teams, there’s a couple of obvious improvements that can be made:

  • each success criterion would be more useful if it gave an idea of which disabled audiences would benefit from conforming with the criterion, and a rough idea of how much it might cost to conform to it
  • the criteria could also be made easier to read, and it would be useful to structure them via job-roles so it’s easy to know which member of a website creation team needs to deal with each criterion

The main weaknesses, however, are WCAG 2.0’s incompleteness and lack of future-proofing.

The Uni of York paper found that numerous problems that disabled people experience with web pages are not covered by WCAG 2.0. This is certainly true, especially for the needs of people with cognitive, learning and literacy difficulties – disabled groups that were under-represented in the creation of WCAG 2.0.

So, covering more problems than WCAG 2.0 currently addresses could potentially improve WCAG, if it’s to be used on its own to improve accessibility.

However the paper’s assertion that ‘we must address all the problems that disabled people find on web pages’ is over-stated, as the variety of disabilities that people have, and the interaction of those disabilities with those people’s length of experience in using the web, means that it may be impossible to address all problems.

Moreover, it’s debatable whether many of the missing success criteria to address those missing problems are accessibility or usability issues.

I agree with WAI that including all potential website usability problems, whether shared by disabled and non-disabled people or not, in a notional future WCAG may not be the answer.

But the distinction between ‘issues that block access or interfere with access to the Web more severely for people with disabilities’ and ‘general usability issues’ can be rather murky, especially for WCAG 2.0’s very useful success criteria on error conditions for forms and headings (see Roger Hudson’s great blog on ‘the absurd distinctions that are sometimes made about the usability and accessibility of web content’).

So, if it’s not totally clear which issues should be allowed in WCAG 2.0 and which shouldn’t, I think it’s important to be clear that conformance with WCAG isn’t the only thing website creators need to do to make sure their sites work for disabled and elderly people.

And it’s important to be clear that WCAG is never going to be complete or future-proof. The web is too fast-moving for web guidelines to ever be complete. WAI did a great job attempting to make WCAG 2.0 technology agnostic, but they didn’t future-proof it with regard to mobile/tablet sites.

But it’s also important for WCAG to at least try and keep up with technology. As Richard Morton contributed on linkedin:

“I would also say that unless the WCAG 2.0 guidelines are updated to remove some of the anomalies, and make it fit for purpose with the changes to the web scene over the past few years since it was released (e.g. much more mobile/touch based access, responsive websites, apps), then it could create more problems, and result in a backwards step.”

If the aim of accessibility is to give a great web experience to all people, including those who are older or who have disabilities – which is how WCAG 2.0’s proponents are selling it – WCAG 2.0’s success criteria will need to be frequently updated, because currently it just isn’t enough to do that.

And it needs to balance how often it gets updated to become more relevant, true and complete, with ensuring its slow-moving enough to give website creators a target they can hit.

Strengths and weaknesses of WCAG 2.0 conformance levels

wcag conformance badgesWhile I’m a great fan of WCAG 2.0’s success criteria, I can’t say the same for its conformance levels.

The idea of conformance levels is definitely attractive:

  • it gives website creators an idea of the importance of complying with each individual success criteria;
  • it gives websites a means of ‘badging’ their level of conformance, which is also very useful for regulators and legislators

However, the implementation is fundamentally flawed.

Assignment of the level to each success criteria

Let’s start with the assignment of levels A, AA and AAA to each success criteria.

This is currently flawed as a practical tool for helping website creators prioritise their accessibility work, as the levels don’t take into account two important aspects of modern website creation:

  • the vast variety of purposes of a website – especially for media-rich and user generated/social content
  • the cost-benefits of each success criterion

To give the simplest example of the problem of purpose:

  • Criterion 1.2.5 requires all pre-recorded video content to be enriched with audio description. What this means is that for a site that includes video to achieve AA it needs to include audio description on all its pre-recorded video. So, for example, a user-generated video sharing site like YouTube could never achieve AA without requiring all of its users to include that audio description themselves. So YouTube’s owners would need to change the site’s purpose, or decide that WCAG 2.0 AA isn’t worth bothering with. To deprive websites of using video and social media because of unreasonable accessibility constraints is the type of bad guidance that enables web developers to claim ‘accessibility is anti-creative‘.

And here’s a simple example of the problem of cost-benefits:

  • The number of people who benefit from captions being provided for video content is huge, and the cost is reasonable. Comparatively, the number of people who benefit from audio description (or an ‘alternative’ to video) is very small, and the cost is large. And yet none of this essential information is mentioned in the success criteria, and both are set at level A in WCAG 2.0.

WAI’s assignment of levels to WCAG 2.0 success criteria only really considers the needs of individual disabled users (specifically the users whose needs where championed in WCAG 2.0’s creation – so, not so good for cognitive, dyslexic, learning difficulties), and doesn’t include an idea of the number of people who will benefit from following each criterion (e.g. how many people there are in those disability groups), or any idea of the cost of implementing each criterion.

While it is sometimes hard to pin down how much each different group of disabled people would be helped by each success criterion, as criteria regularly help more than one group, WAI don’t make it obvious that any cost-benefits thinking was involved in their thinking, despite publishing useful statistics of prevalence of different disabilities.

This means that individual organisations trying to make their sites accessible often have two options:

  • Stick dogmatically to the level of each individual WCAG 2.0 success criterion, however much they think it does or doesn’t make pragmatic sense (this is generally done by organisations that have WCAG 2.0 compliance required of them – let’s call them ‘Category 1 organisations’); or
  • Do their own cost-benefits analysis of each success criterion, to decide whether or not they are going to comply (this is generally done by every other organisation that is allowed to come up with their own accessibility aims – let’s call them ‘Category 2 organisations’)

Conformance levels and logos

And, unfortunately, WCAG 2.0’s conformance rules makes things even worse, as conformance is marked against perfection in achieving all success criteria at a given level.

This means that, for WCAG conformance purposes, it’s no better to have a site that obeys all but one of the many Level A success criteria than have a site that doesn’t even know that WCAG exists.

So, to use my two types of organisation, from above:

  • Organisations in category 1 tend to try and conform, then ‘wriggle’ and try and come up with ways of getting around problems using exception processes like the “comply or explain” principle in Holland’s national accessibility guidelines.
  • Organisations in category 2 may make the hard task of deciding which of the success criteria is sensible themselves, hoping no-one’s going to argue too strongly with their decisions; or, more likely, take WCAG 2.0’s lack of commercial pragmatism as the perfect excuse to not comply with any of WCAG.

WCAG 2.0’s emphasis on needing to score perfection on all the success criteria on each level to get the level conformance logo completely mis-understands the realities of web product development – in website development perfection is not something you strive for; you aim for continuous, pragmatic improvement over versions.

It also places huge strain on the committee making sure that the success criteria are perfectly categorised into levels, as one mistake considering the reasonableness of assigning a success criterion the right level can (and, as we’ve seen, does) make it impossible for some websites to achieve any level of conformance.

The fact is that while idea behind conformance levels is attractive to anyone creating a Standard, and to those wanting simple metrics for governance, I’ve never seen a categorisation of success criteria into levels that created more positives than negatives.

Detlev Fischer nicely summarises the positives in his comment on my EU accessibility law blog:

“The advantage of WCAG is that it is out there as a recognised international standard, ready to assess a site’s status regarding many vital a11y requirements, and ready to inform many significant improvements. Good usability is much more context-dependent and harder pin down, so compliance to an augmented set of guidelines would be much harder to impose and measure in the way that WCAG 2.0 level AA conformance might be imposed and checked…”

But here are the negatives from my response:

“The worry is that WCAG 2.0′s flaws and inflexibility are going to make each case where WCAG 2.0 AA compliance is unreasonable into a shouting match that may give accessibility a bad name.

I’d also agree that compliance to an augmented set of guidelines would be harder to impose and check. But I think imposing and checking against any set of site creation guidelines slightly misses the point. It’s the results of following the guidelines that are important, not the following of them itself. Put it this way – you wouldn’t assess the usability of a website by assessing the guidelines the design and build team used to create the site; you’d measure the usability of the site itself, in terms of effectiveness, efficiency and satisfaction defined by ISO 9421-12. So the only reason that assessing usability for disabled people should be any different is if the cost of doing such usability measurement is unreasonable itself… different types of testing/measurement methodologies have different cost-benefit dynamics, and so the site owner themselves should define the amount of money they think is reasonable to give them the level of confidence they need that their site has achieved its inclusion goals.”

Strengths and weaknesses of WCAG 2.0 stability and static-ness

Old weathered church in the middle of modern skyscrapersSo, if WCAG is useful, but needs improvement, is that improvement likely soon?

One of WCAG 2.0 main strengths is its stability. Certainly WAI promote its stability in this quote from their press release on its approval as an ISO/IEC standard:

“As an ISO/IEC JTC 1 Standard, WCAG 2.0 is now also available from ISO/IEC, while it remains a stable international W3C standard with extensive supporting resources. JTC 1 recognition neither changes nor supercedes the existing standard, which remains freely available from the W3C website along with multiple W3C authorized translations of WCAG 2.0.”

Reliability and dependability are very useful aspects of WCAG 2.0’s stability. And it’s questionable if WCAG 2.0 would have become an ISO/IEC Standard if it wasn’t stable.

However, another aspect of stability is ‘resistance to change’ and, for want of a better term, static-ness. And it’s this static-ness that is WCAG 2.0’s main weakness, as it tends to divide accessibility experts into two extreme camps:

  • defenders of WCAG, who tend to see any questioning of the Standard – including any critique or research that points out any flaws in it – as an attack to be rubbished
  • critics of WCAG, who tend to look at WCAG as the orthodoxy of accessibility to be critiqued and questioned, sometimes with an unfortunate undercurrent of ‘we weren’t invited to feed into WCAG before it’s adoption as a standard, so we’re going to throw stones now’

It’s a reflection of WCAG 2.0’s success that, like any successful, influential thing in history – whether it’s a document, a movement or an ideology – it attracts both devotees and detractors.

But, as much as I dislike the under-appreciative tone of some critiques of WCAG, I really hate the attack on new research in accessibility, if that research doesn’t ‘fit in’ with the orthodoxy of WCAG.

Like any good idea, if WCAG is a great set of guidelines it should be able to stand up to rigorous critique.

And like the best ideas, if that critique finds WCAG wanting, it should be big enough to flex to accommodate that new thinking.

So the whole accessibility community should welcome the publishing of new research, like that from York and Norway in 2010, especially as much of the best research done on accessibility is commissioned for companies that are reluctant to publish the results for commercial reasons (at the BBC, I had similar research done into how well WCAG audits could predict problems identified by user-research, and found it similarly wanting).

All such published research adds to our understanding of the complex relationships between disabled users, accessibility guidelines, assistive technologies and usability outcomes.

As someone who has gone through the no-sleep-for-months hell of getting a Standard out there, it’s obviously frustrating to the drafters of WCAG 2.0 for the its value to be questioned.

However, WAI shouldn’t push criticism away. No Standard is perfect. And having your baby’s imperfections pointed out is only threatening if you don’t have any possibility or intention of fixing those imperfections.

W3C’s current way of ‘fixing WCAG 2.0’ seems to create supporting documents like Understanding WCAG 2.0 that can be updated more regularly than the Standard itself.

But more than this is needed.

A better way forwards

So can we imagine a better way? How about this?

Imagine a future where, instead of the crude A, AA and AAA, you could:

  • Score a site’s accessibility against how many accessibility success criteria you’ve achieved (even including a multiplier for their importance based on the number of people affected), rather than whether you’ve reached a certain level so you can get a badge. Your step-by-step advances in accessibility through a site’s versions can now be reflected in its increasing accessibility score.
  • Score the site’s accessibility against the needs of different disabled groups – e.g. a video site which doesn’t include audio description may be perfectly accessible to most disabled and non-disabled people; it’s deficiency is just a problem for blind and VI people. You can now let disabled people know these specific deficiencies in the site’s accessibility statement (the ‘limitations’ recommended by BS 8878), which will be much more useful to them than placing a WCAG conformance logo on the site.

Imagine a future where this release from crude conformance levels and notions of completeness allows WCAG to cease to be the static battering ram that it is now, but allows it to flex over time (possibly moderated by the proposed International Society of Accessibility Professionals):

  • New success criteria can be added, when they are proven to have an impact on users, and when sufficient techniques are proven to lessen that impact.
  • Existing success criteria can be promoted, demoted or removed as they are found – by the best research we can find – to be more or less important than we first thought.

Moreover, imagine a future where WCAG 2.0’s technical approach to accessibility is placed within a framework that allows accessibility to be more effectively considered from a product perspective, from an enterprise programme perspective, from a technology strategy perspective, and from the high-level national and global perspective of how governments can legislate and encourage accessibility.

That is what BS 8878 provides, and I would suggest that all legislators take a good look at it, because it:

  • provides a more nuanced model for measuring accessibility, and for sensibly handling situations where the website development team can reasonably manage all of WCAG 2.0’s AA success criteria except one or two;
  • provides a way of enabling organisations to embed accessibility considerations in their working practices so they can consistently produce accessible products.

How do we make this happen?

The problem with WCAG 2.0 isn’t that it’s not perfect; the problem is that it’s static and WAI are resistant to updating it, so its imperfections are argued over, rather than improved upon.

Having led the creation of a Standard – BS 8878 – myself, I know it’s not a trivial thing at all to try and create an updated Standard. And it’s not guaranteed that a WCAG 3.0 would automatically be better than WCAG 2.0, even with the insights we now have into WCAG 2.0’s deficiencies.

But I think it’s worth an open discussion to see whether there is consensus for a new direction for WCAG 3.0.

And, in the meantime, we have to go forwards with what we have – warts and all.

We can’t afford to wait for the perfect accessibility Standard to come along – it will never exist.

The problem isn’t that WCAG 2.0 isn’t any good; the problem is that it is being used for things that it’s not designed to do well. It’s a mistake for anyone to claim more than it can do, especially when advocates start using huge numbers of disabled people to motivate organisations to follow WCAG, when WCAG 2.0 doesn’t sufficiently make clear how its success criteria guarantee to help each of those audiences, or the cost-benefits of doing this.

What we need to do is to be very careful about how we apply the best accessibility standards that we have at any one time – making sure we use them for what they’re good at, making sure we don’t use them for what they’re not good at, and using the best insights we have to know the difference, with the courage to have the humility to say when we just don’t know yet…

So, what do you think?

Is WCAG 2.0 fit for legislation? Or do you also have concerns?

Have you experienced occasions where WCAG 2.0 has clarified exactly what you need to do to make your website accessible?

Or have you found it less useful?

Let us know by commenting below.

Want more?

If this article has been useful, please sign-up for the Hassell Inclusion newsletter to get more insights like this in your email every other week.


Deaf says

The issue with AAA is regarding sign languages – only a small percentage of culturally Deaf people use it (the majority of deaf and hard of hearing people rely mainly on captioning/subtitling), and sign language is not the same for each country. Also, signing people do not consider themselves disabled, but a “cultural” minority.

More about this issue is on:

There’s an excerpt from that article: “Now, the fact that there are many different sign languages around the world is not really a matter of disability access so much as it is a matter of internationalization, but the fact that there are vast differences between the sign languages of those who can read the same spoken language (e.g. English) is very much a matter of disability access. The common thread between those who speak ASL, BSL, and Auslan is not sign language, it is English—even when you take into consideration the regional differences of spelling and some vocabulary words.”

Jonathan Hassell says

Hi Svetlana,

Thanks for your comment.

Yes, you’re right regarding the number of people who benefit from captions/subtitles compared to the number of people who benefit from signing, and I’m aware of the cultural issues around sign language, having done lots of work with the signing community in the UK.

The interesting thing, with respect to the points in my article, is that the assignment of level to sign language success criteria (WCAG 2.0 SC 1.2.6) actually seems to have some cost-benefits thinking behind it. While captioning is at levels A and AA, sign language provision is at level AAA. And that makes cost-benefits sense. What doesn’t make sense, however, is the thinking behind making audio-description level A, when it has reasonably similar cost-benefits to sign language provision (if you take the issue of internationalisation of sign language out of the equation).

It’s this sort of inconsistency, and lack of transparency, in WCAG 2.0’s cost-benefits thinking that is the weakness.

Birkir Gunnarsson says

As much as I would like to disagree with this article (as it is a bit commercial in nature pushing the BS 8878 standard) 😉 I think it is well written and absolutely right actually.

I am pushing for, and consulting on, the implementation of WCAG 2.0 AA compliance for public sector websites in a small country, and have already run into people questioning its usefulness and pointing out a few of the things mentioned in this article.

Along with my colleague, I am also carrying out research on another missing link in some WCAG guidelines (most specifically guideline 2.4), which has to do with some disconnect between website designers, Assistive Technology vendors and end-users. The premise of the research is that a fairly small minority of, for instance, screen reader users are aware of the the usefulness of headings and logical order of heading levels, or are not aware of the existance of landmarks, and these things, though extremely useful to those who take advantage of them where they are implemented, end up not being appreciated or used much. Users have sent multiple complaints about difficulties navigating a national public radio website to me, because they only navigate the site by tab or arrow keys, even if the site developers have implemented landmark support and logical heading structure that will get the user directly to the main area of each of the site’s pages.

Basically though, it is neither part of the standard necessarily, nor the role of the WAI, I think more support material needs to be developed along with an accessibility standard that communicates the usefulness or benefit of said criteria when implemented to the end user. It is somewhat futile to implement all the success criteria of WCAG (or any standard for that matter) if the users do not even know of them and keep sending you complaints regardless.

The research is on-going and will first be presented at CSUN 2013, but we expect and hope to turn it into a paper and, best case scenario, a website with drafts of user guides for web browsing with at least the basic screen readers, though it depends entirely on our employers, funding and other commitments. I still think this is relevant to the contents of this article, and I am definitely happy to see such candid and thoughtful views on how we can take a good thing and make it even better.

Jonathan Hassell says

Delighted your experience in Iceland chimes with my blog, Birkir, even if you think it is ‘a bit commercial in nature’.

Hopefully that means you may be able to use my post to help with your discussons with those people questioning WCAG in Iceland. As I say in the blog – while WCAG 2.0 isn’t perfect, that shouldn’t be used as an excuse to not work with it, but as the start of a meaningful discussion. If I can help in any way, please contact me.

On that commercial point, I should say that, while I led the authoring of BS 8878, I don’t make any money from anyone buying it at all, and personally would have preferred the Standard to be free like WCAG. The reason I promote it is the same reason I and the rest of the authoring committee wrote it – because we believe it’s the missing link that WCAG needs to be really successful.

And thanks for identifying another of the limiting factors for disabled people getting a great user experience of websites – limits in their own education in getting the best from sites using the assistive technologies they use.

I completely agree that this is a key issue – it was the reason why I commissioned My Web My Way when I was at the BBC, to ensure disabled people and their supporters knew about the accessibility customisation features of the computer and browser they use, and the assistive technologies available to them.

Your research takes this education to a much deeper level – of how people should best use the assistive technologies they have to get the most from WCAG coding. I think this is really needed, and salute your identification of the need, and your ability to attract funding for you to work to meet that need.

I’ll be at CSUN 2013, so I’ll definitely come by your presentation. And if there’s anything I can do to help promote your results, when they are ready, just ask.

Mark Palmer says

“each success criterion would be more useful if it gave an idea of which disabled audiences would benefit from conforming with the criterion, and a rough idea of how much it might cost to conform to it”

Exactly Jonathan, which was why this was one of the key elements I added to the subset guidelines I created for the Abu Dhabi Government (note: this does not mean that I agree with separate national guidelines).

My experience of using WCAG 2.0 is mixed. They are definitely a huge improvement on earlier iterations but are still cumbersome, confusing and bloated in places. Test participants I work with still regularly hit barriers in their day to day use of the web which are not covered (or are inadequately covered) by the WCAG 2.0 guidelines.

Jonathan Hassell says

Many thanks for the comments, Mark.

Glad to hear your guidelines for Abu Dhabi included info on which audiences benefit from each criterion. Are they available online for people to learn from?

And, yes, my experience of user-testing chimes with yours re finding barriers that aren’t adequately covered in WCAG 2.0.

The knowledge of these ‘missing barriers’ often becomes part of the value-add that experienced accessibility specialists bring to their consultancy and testing.

So one challenge for the creation of WCAG 3.0 would be to encourage those of us with this experience to generously and freely share our missing or updated success criteria so that everyone can benefit…

Mark Palmer says

Hi Jonathan. Unfortunately these guidelines are not available online or as far as I am aware even publicly available by any other means.

With regards to any future WCAG 3.0, I totally agree.

Jonathan Hassell says

That’s a shame, Mark – they sounded like they could be a useful step towards WCAG 3.0.

Birkir Gunnarsson says

My comments regarding BS8878 should definitely be taken as tongue-in-cheek, certainly not as a criticism.

Thanks for your response, and I am looking forward to seeing you at CSUN. I will attend your presentation(s) if you have some (have yet to review the schedule).

One thing you mentioned, and I find highly interesting, is the breakdown of WCAG criteria by role (and of course approximate cost). I have gathered some info on this, and I an incorporating this into an Excel spreadsheet (coming from a banking job, I use Excel for everything, but it works great for some things). If you have any info on either team roles or expense, that you can share, I would be happy to both insert it into my worksheet as well as, of course, send it to you or publish it for everyone who might benefit. Any other parts of BS 8878 that I could read or explore without paying will certainly be explored.

Thank you again for highly insightful blog posts and a fresh take on internet accessibility issues.

Jonathan Hassell says

Hi Birkir,

I’m presenting twice at CSUN with some American business associates of mine: once with Jeff Kline on How a Policy-Driven Adoption approach could help drive accessibility globally; and once with Debra Ruh on Helping Corporations Embed Accessibility in their culture. I’m really looking forwards to both.

Regarding your spreadsheet on breaking down WCAG criteria by role: yes, let’s share what we’ve both got and see what we can come up with – I’ll email you offline.

Finally, you can find lots of free information on BS 8878 at BS 8878 web accessibility standards (supersedes PAS 78) – all you need to know.

Michelangelo Iaffaldano says

[…] ‘resistance to change’ and, for want of a better term, static-ness.

Well, English does have a better term: staticity. 🙂 Aside from this pit of pedantry I agree with your post all the way. I especially like your suggested improvements on the scoring system.
As UX professional I like to focus on a qualitative, results-based view of accessibility, which largely overlaps with usability. In other words: never mind the guidelines, are we helping people or not? Unfortunately, when dealing with unsympathetic or uninformed organizations it is often easier to speak of “standards” and “compliance” in narrow, normative terms.

Jonathan Hassell says

Hi Michelangelo,

Thanks for the term correction, and glad you like my suggested improvements on WCAG’s scoring system 🙂

Completely agree with your qualitative, results-based view of accessibility. That’s the viewpoint that BS 8878 comes from too.

Were you aware of it already? And what do you think of it, as a UX professional?

Felix Miata says

WCAG 2.0’s incompleteness is highlighted by its woeful attention to legibility. The ironically tiny little 1.4.3, 1.4.4 and 1.4.6 sections are essentially all there is on the subject of legibility. Text size and contrast are fundamental elements of legibility, which in turn are fundamental elements of basic accessibility.

1.4.3 and 1.4.6 indicate that contrast level required is affected by text size, yet mention only a reduced need as size is increased, omitting attention to the larger problem that reducing text size below optimal makes adequate contrast even more important. Gray text at less than 1rem cannot be a component of success in a set of comprehensive and legitimate accessibility guidelines.

To say that resizability is either a success criteria on its own, or an element of a more comprehensive success criteria, dodges a much larger issue of how unfriendly it is to not adopt the user’s presumptively optimal pre-selected text size, the user agent default, as the dominant size of text on web pages.

Visitors shouldn’t need to re-size text. They selected their optimum sizes when they accepted the OEM user agents’ default sizes, or personalized them to their varying needs. The majority of text should be the visitor’s preselected optimum size in the first place, 1rem, whatever size in pixels or points that may be.

Re-sizing of text is a reaction, a defensive response to an offensively presented page. Sub-1rem text dominating a page is rude, and should not be considered success under a complete set of legitimate accessibility guidelines.

Jonathan Hassell says

Thanks for your comment, Felix.

Yes, I definitely think WCAG 2.0 could be more nuanced in its attention to legibility, especially as contrast is a much bigger issue than just minimum levels for people with vision impairments (many people who are dyslexic or have Aspergers’ would be better helped by a success criteria around maximum levels).

There’s a huge number of individual issues which need improvement that could be detailed. But this isn’t the place for that.

What I’m interested in are ways we could improve WCAG 2.0 without depriving industry of necessary stable accessibility standards while we go about it…

thomas says

I like WCAG
and I can’t deny

Jonathan Hassell says

That’s great for you Thomas. Anything in particular you like about it…?

Martyn Cooper says

In a review of WCAG 2.0 by members of the Open University’s Web Accessibility Standards Working Group (which I chair) we considered that some of the AAA guidelines should have a higher priority in an eLearning context and that some of the AA ones were not so critical or relevant to our audience. This makes simple statements like working to WCAG 2.0 AA not easy or helpful to make to reflect what we aim for in terms of accessibility. However the legislation I have seen drafts of does make such simple statements! This presents a challenge!!!

Jonathan Hassell says

Thanks for this, Martyn.

That’s a really useful finding, and reinforces the point I make about the levels assigned to success criteria currently not taking into account the variety of purposes of a website. In the blog, I mention user-generated video content sites. And now you’ve added eLearning sites as well.

How a notional WCAG 3.0 could take into account the wide variety of website purposes when levels are being assigned to success criteria – so some SCs might be at one level for one sort of site, and another level for another sort of site – is very challenging.

But it is needed if WCAG conformance is to be applied without some accompanying exception process to handle situations where these sorts of difficulty occur, especially when the link between WCAG conformance and the law is made.

Roger Hudson says

Thanks for a very interesting article. Like you, I strongly support WCAG 2 (and see it as a great improvement on WCAG 1) but have a number of concerns. I am a little worried about the general approach to conformance levels and some of the levels given to different S.C. I fully agree with your comments about 1.2.5 and can’t see why it is at AA (IMO it should be AAA), particularly when, for example, the need to use headings to organise content (2.4.10) is at AAA.
I am also worried by the way regulators and some developers consider accessibility just in terms of meeting a particular level of conformance, rather than how easy or difficult it will be for people with disabilities to use a site or site component. At the end ot 2011 I developed an additional scoring system, which looked at issues from the point of view of likely accessibility barriers ( I have used this system over the last year when evaluating sites, and clients have generally found it useful in helping identify which issues to address first. Following feedback, I have recently revised the system and plan to write another article about it in the near future, and I will be talking about it in a presentation at CSUN 2013.
Thanks again, and I look forward to meeting you at CSUN.

Jonathan Hassell says

And thanks to you, Roger, for your great article that I quote in my blog – I love it when different minds are on similar tracks at the same time.

Your accessibility barriers scoring system sounds great, and a little like something I use to help my consulting clients prioritise. Many thanks for the link, and I look forwards to meeting you at CSUN to discuss them further over a beer/coffee.

Jenny Bruce says

I agree 100% with Roger about 1.2.5 needing to be a AAA criteria. Another AAA criteria that is significantly easier to implement (IMO) is criteria 3.1.4 Abbreviations and would probably benefit more users than 1.2.5.

Ian Hamilton says

Have you had a chance to have a proper look through the game accessibility guidelines site? There’s still stuff to come on it (some filtering by roles & genres would be great, but that would need a developer to be working on it) but it works to address quite a few of the things that you’re talking about.. such as basing levels on cost/benefit instead of just benefit, easier to read, bank of prioritised best practices instead of compliance levels, focus on cognitive, etc.

What you said about different purposes is particularly relevant for games. That’s the real difference with game accessibility, that it absolutely must have barriers in it or it can’t be classed as a game, so a decent (and easy) system of taking that into account would be pretty useful.

For my money the biggest failings of WCAG are firstly its complete inaccessibility to people without prior experience, and secondly the language used throughout. Operable/perceptible/robust/understandable may have looked great on paper in an academic sense but really they bear zero relation to either disabilty or people’s working practices. Explaining things in the basic WHO motor/visual etc classification is a much more effective way to get the point across to people.

Jonathan Hassell says

Thanks for this, Ian.

I’ve (finally!) had a look at your game accessibility guidelines and I like a lot of what I see. Great work!

It’s great to see you using Reach, Impact and Value (R-I-V) as the factors for whether guidelines are put in basic, intermediate or advanced (which are all well-named categories). This is exactly what I use for helping advise my clients on how to prioritise fixes revealed by audits as necessary. It might be even better if you could show more transparency in detailing how you estimated the R-I-V for the guidelines (for example, what statistics of prevalence of different disabilities you used to estimate reach; what user-research you used to estimate impact; and how you estimated comparative implementation costs for game creation projects of different scales).

And, while I think your classification of guidelines via impairments users have is much preferable to WCAG 2.0’s POUR classification, I think classification via job-role would be more immediately useful for users of your guidelines. If I was project/product managing a game’s creation, and liked the idea of taking accessibility seriously, I’d want to give each of the different members of my team a short list of guidelines of how what they do impacts the accessibility of the game, and make them responsible for following them. In the end, it’s nice for a visual designer to know that their choice of colour is going to have particular impact on people with low vision and dyslexia; but it’s more important for them to quickly get to the guidelines that affect their work without having to go through guidelines that don’t.

So we have three dimensions we could organise the guidelines around:

  • job-role the guideline impacts,
  • impaired person the guideline helps,
  • cost-benefits of implementing the guideline.

At the moment, you’ve organised your guidelines according to this priority ordering:

  1. cost-benefits of implementing the guideline,
  2. impaired person the guideline helps,
  3. job-role the guideline impacts.

But I think the best priority ordering for usefulness on a project would be:

  1. job-role the guideline impacts,
  2. cost-benefits of implementing the guideline,
  3. impaired person the guideline helps.

What do you think?

Ian Hamilton says

Yep I reckon RQIV was the single best thing I saw at the BBC while there, allowed so many great things to happen. The world would be a far better place if more things were run on that thinking!

Glad you like it! The way it is came from the kind of questions that are most commonly asked… as well as the big well known studios there’s a huge indie community with a particular surge in bedroom developers working in 1s and 2s, who don’t have either producers or clear divisions between roles. Questions people most commonly ask are about a specific type of impairment, or what can be done to make a difference for minimal cost.

But all I’m talking about is what the top most useful thing to divide by is, I couldn’t agree more with you about the roles also being a useful split. The original ambition was to include that, and also two other things – being able to cut the data by genre of game (eg. puzzle), or specific impairment (eg. dyslexia).

Had to let those things all go due to not having any developers working on the project, so we were restricted to just what WordPress can do out of the box.

That’s still the hope though, to be able to get something like that in, ideally some funding to pay a developer to make some proper combinable filters (eg. show me the basic level guidelines for artists working on a racing game), or some kind of basic mutually exclusive fudge just using standard WordPress tags.

In general though the structure is a reaction to / progression from WCAG, in exactly the spirit of your original post.. building upon what it’s very good for, while trying to address some of the weaknesses.

If anyone else is interested, you can see the site we’re talking about at – WCAG style resource for games industry, angled as suggestions rather than recommended compliance levels.

Ian Hamilton says

Something else on that note actually that I’ve fond really useful in encouraging people to care about accessibility, is actually doing that work you’re suggesting on WCAG. Showing a visual designer a document that mentions code semantics is a 100% guaranteed way to get them to think that accessibility is an irrelevant waste of time.

So I’ve in the past produced filtered versions of WCAG, separate printed documents for each of the disciplines listing only the guidelines that are relevant to them, and also completely reworded them into not just plain English (which WCAG sorely lacks), but actually using terminology that the different disciplines are familiar and comfortable with.

Then sat in a room with the disciplines, and actually read through the documents with them before work started, and got their buy-in from the outset.

It’s not perfect, they still needed lots of reminding at prodding, but the fact that they had already agreed to something that was only about a dozen completely relevant bullet points as being something easily achievable made it far far easier than it would be otherwise.

Jonathan Hassell says

Great to see you doing this too, Ian. This way of working, for me, is the best way of evangelising accessibility. Gaining buy-in from individual team-members to start doing accessibility bottom-up. Then discussing the business case for doing accessibility with the product manager to gain a top-down commitment. Get those sorted and you’re really cooking!

The only thing I’d add is to maybe to highlight the good accessibility decisions people are already making early. For example, product managers who choose to include videos should be first told that they are already helping millions of people with literacy difficulties by doing so, before being informed of the need (and cost) of captions, audio-description etc.

These are examples of best practice ways of getting WCAG 2.0 accepted by teams. It’s just a shame that they aren’t the way WCAG 2.0 is structured itself.

Jonathan Hassell says

Thanks for pointing out the indie community who don’t differentiate so clearer between roles. Good point! Yes, – different organisations need different ways of being most effectively introduced to the same body of guidelines.

Amajjika says

Jonathan, great article.
In relation to WCAG 2.0 being divided into job roles, Access iQ has two resources that are of great help.

The first is the Web Accessibility Wizard designed by my colleague Sarah Pulis. She has catalogued all 512 Success Criteria according to a detailed meta data schema. The result is you can do a search on topics or job roles and have all the relevant Success Criteria returned to you in a search. This tool is freely available for all to use and accessed via a the home page.

The second tool are our premium guides which are for sale. We have taken the WCAG guidelines divided them up into job roles and written about each in plain english providing examples and code snippets. We currently have guides for Content Authors and Developers Guide. The Designers Guide is due in late March. Highly useful, easy to understand and comprehensive – you won’t find a better desk reference in one location.

I think it’s important to note that Access iQ are owned by Media Access Australia an independant not for profit who advocates for equal access to media and technology for users of all abilities. In working with our mission, we realised that assisting industry and government in their understanding of how to achieve web accessibility was pivotal so Access iQ was launched.

Access iQ is a social enterprise, a NFP that trades to fulfil its mission and we believe the only sustainable way for advocacy organisations moving forward: provide something of real value to organisations and government in a timely fashion to ensure the ongoing sustainability and independance of the organisation and achieve freedom from needing donations, government funding and an over reliance on volunteers.

This ensures we can continue to place our energy where it is needed most to achieve our vision of a web without limits.

Jonathan Hassell says

Thanks for this Amajjika.

Yes, Access iQ’s Web Accessibility Wizard is useful. Readers, here’s the link:

And I’d agree that advocacy organisations do need to provide valued, professional services to be effective and sustainable.

For too long accessibility has been characterised as something that passionate people attempt to get organisations to adopt by telling them some variation of “it’s the right thing to do, and it’s free”.

For accessibility to be taken more seriously by industry, it needs to become something that organisations see is worth doing because it makes business sense to them, and they are able to find implementation support from experienced professionals that not only understand accessibility, but also its value (alongside user-experience, security and availability) to organisations.

Detlev Fischer says

Hi Jonathan,
While I agree with many points in your article, I’d like to address three points you make: academic research, identifying disabled audiences and indicating cost of conformance.

First, academic research into the effectiveness of WCAG. I think the academic research by the University of York which you link to as evidence of WCAG’s shortfalls is flawed beyond the points you raise yourself, and said so in an article a while ago (

Second, disabled audiences. While it is true that there are many types of disabilities that are affected in very different ways by accessibility shortcomings, the greatest achievement of WCAG is to aggregate all these requirements so that people concerned with commissioning, designing, and implementing web sites and web applications need not grapple with this complexity.
If you are really serious that WCAG guidelines “would be more useful if it gave an idea of which disabled audiences would benefit from conforming with the criterion” you would make WCAG even longer and even more complex than they are today. Just taking something as complex as ‘visual impairment’, do you really think it would help patrons, designers, editors etc to understand that while the elderly will need just a slight increase in text size, others need magnification tools while still others (e.g. when affected by retinitis pigmentosa) might actually reduce size? That some need high contrast settings, while others need inverted contrast or even muted contrast, and so on ad infinitum?
I have always seen sense in the credo I heard from people with disabilities that they do not want to be pigeonholed by type of disability – hence the emphasis on universal design. Cue comprehensive guidelines that try to integrate all the different needs of the community out there. If we accept this, it is clear that any one guideline will necessarily need to compromise, and that it will never fully cover all the needs of all groups.

Third, cost of conformance. This varies a lot with the type of implementation and can hardly be generalized in Guidelines. It may be changing just a few lines of CSS, or it may be a complete re-launch of a site in a better-suited CMS. I am not saying here that this point is not important, it is – it just has to come in as part of your specific consulting, not as part of a guideline assessing the degree of accessibility of any given site or system.

Having said all that, it is clear that a process-based approach that includes decision makers’ awareness, the tendering/purchasing processes, education and human skills, maintenance issues etc. is very important to ensure that accessibility is better integrated in the corporate / organizational culture. Still, I see no conflict in having process guidelines line BS 8878 on the horizontal level and something like WCAG 2.0 vertically embedded at particular points to verify the state of accessibility, suggest fixes, re-test to ensure sustainability, and so on. Process guidelines and WCAG just have very different roles in the entire picture.
While WCAG conformance strives to be testable (which is hard – and I agree that the emphasis on pass/fail conformance is not productive here), the success of process implementation is arguably less so – at least any assessment will probably have to take into account a host of soft and contextual factors.
As to the need for a ‘WCAG next’ as Jared Smith termed it, I agree with others that some success criteria are not prominent enough (2.4.7 Focus visibility being a good example) or actually weaker than in WCAG 1.0 through the inclusion of loopholes (like the option to meet contrast requirements through styleswitchers without any default requirement). While I agree that WCAG should be updated to fix its clear deficiencies (and probably not for the last time), I think much of the continuous future-proofing can and should happen via the WCAG Techniques.

Jonathan Hassell says

Hi Detlev,

Many thanks for your comments. Great to have sparked so much discussion through my article – that was my intention.

Thanks for pointing out your article regarding the flaws in the University of York’s research. The reason I made mention of that research, and the Norwegian research, is that these are the only publicly available examples of the sort of research that many commercial organisations have also done. It’s unfortunate that the York research isn’t completely watertight, but it has been very useful in prompting further useful discussion (like your useful article).

I agree that there is a tension between including information on which disabled audiences benefit from conforming with each criterion and keeping the length of WCAG to a reasonable level. But isn’t that the whole point of hypertext? – that such useful information can be provided as links for people to follow if and when they wish. While some people would be happy to just accept WCAG as ‘the rules’ without any such information or corroborating evidence of usefulness, others will want more proof, especially when the criterion they are being required to comply with makes onerous or impossible demands on their resources.

I also appreciate your point that cost of conformance can vary with the type of implementation, and so consultants are better placed to provide this information than the guidelines themselves. But the implication of this is that the costs and benefits of each criterion are only properly understood in the context of the website creation/maintenance project in which they are being applied. If this is the case then WCAG 2.0 shouldn’t assign criteria to levels. As WCAG 2.0 (rightly) does organisations need to be sure that they are helpful in giving guidance on what the usefulness and affordability of different accessibility measures are likely to be for most projects. And for that, they need WCAG 2.0 to be transparent in explaining the costs-benefits thinking behind each criterion (again using links to ensure WCAG’s length doesn’t suffer).

To be clear, what WCAG 2.0 is missing is an exception process. Currently it requires you to comply. The only way you can bring your intelligence, your curiosity, creativity or debate to the issues is to decide which of its levels to go for, and hope that there’s some room for manoeuvre in the Techniques docs. But in general you just have to comply. And that means WCAG’s assertions have to be perfect for all situations, which they are clearly not.

Having been responsible for defining, maintaining and governing the application of the Standards & Guidelines for BBC websites in the early noughties, it became immensely clear that guidelines couldn’t anticipate all the products that people were going to create, and that site creators needed an agreed exception process that they could use to challenge the usefulness of conforming to the guidelines for their product. This was as true for accessibility as it was for HTML or CSS validation.

Process standards like BS 8878 encourage members of a team creating a website to be thoughtful about how they make decisions: looking at their options, the implications of each option for the project’s costs and resulting accessibility, and only then making a decision that they think is justifiable. While some accessibility decisions don’t require much thought, others definitely do, and encouraging this way of thinking means that people know how to handle situations where they feel an exception is necessary when they come across it.

So I completely agree – BS 8878 and WCAG 2.0 are complementary in almost all areas other than compliance. They were designed to be so. WCAG 2.0 provides the individual coding, design and editorial criteria that affect the accessibility of a website. BS 8878 provides the organisational, relational, lifecycle, project and product management criteria that affect the accessibility of a website. Organisations applying BS 8878 are given ways of handling exception cases so when WCAG 2.0’s flaws come into focus, they have some possibility of handling the situation, without necessarily needing to reach for an expensive accessibility consultant.

Reply to this thread

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.