UK Web Focus (Brian Kelly)

Innovation and best practices for the Web

  • Email Subscription (Feedburner)

  • Twitter

    Posts on this blog cover ideas often discussed on Twitter. Feel free to follow @briankelly.

    Brian Kelly on Twitter Counter

  • Syndicate This Page

    RSS Feed for this page


    Creative Commons License
    This work is licensed under a Creative Commons Attribution 2.0 UK: England & Wales License. As described in a blog post this licence applies to textual content published by the author and (unless stated otherwise) guest bloggers. Also note that on 24 October 2011 the licence was changed from CC-BY-SA to CC-BY. Comments posted on this blog will also be deemed to have been published with this licence. Please note though, that images and other resources embedded in the blog may not be covered by this licence.

    Contact Details

    Brian's email address is You can also follow him on Twitter using the ID briankelly. Also note that the @ukwebfocus Twitter ID provides automated alerts of new blog posts.

  • Contact Details

    My LinkedIn profile provides details of my professional activities.

    View Brian Kelly's profile on LinkedIn

    Also see my profile.

  • Top Posts & Pages

  • Privacy


    This blog is hosted by which uses Google Analytics (which makes use of 'cookie' technologies) to provide the blog owner with information on usage of this blog.

    Other Privacy Issues

    If you wish to make a comment on this blog you must provide an email address. This is required in order to minimise comment spamming. The email address will not be made public.

W3C WAI Invite Feedback on Website Accessibility Conformance Evaluation Methodology 1.0 Working Draft

Posted by Brian Kelly on 8 Oct 2012

On Monday 20 September 2012 the W3C WAI published the Website Accessibility Conformance Evaluation Methodology 1.0 working draft. The W3C invites comments on this working draft which should be sent by 20 October 2012 to (note that a publicly visible mailing list archive is available).

This is a large document (31 pages when printed) and so I am giving time for those with responsibilities for managing large-scale Web sites to read this document and provide feedback. It should be noted that since institutions may have accessibility policies which claim conformance with WAI guidelines, it will be important that the conformance criteria are realistic and achievable, and that conformance does not add other significant barriers to the provision of institutional Web sites.

It should be noted that the scale of university Web sites will provide particular challenges in achieving compliance. As described in the working draft:

A website may include areas with smaller collections of related web pages such as an online shop, an area for each department within the organization, a blog area, and other parts. In some situations such areas can be considered to be a full, self-enclosed website each. This methodology can be applied to such individual sub-sites (a website within another website) and to the main website in its entirety. However, this methodology may not be applied to a website excluding any of its parts. Excluding parts of the website from the scope of evaluation would likely conflict with the WCAG 2.0 conformance requirements full pages and complete processes, or significantly distort the evaluation results.

The document then goes on to depict a typical University Web site:

and explains how:

In the example above, none of the depicted parts may be excluded from the scope of evaluation in the context of this methodology, if it is to applied to the university website. This includes any aggregated and embedded content such as online maps for the university campus and forms for credit card transactions, including when such parts originate from third-party sources.

Note that the document defines a website asA coherent collection of one or more related web pages that together provide common use or functionality. It includes static web pages, dynamically generated web pages, and web applications“. The University of Bath Web site at is clearly one example of a coherent collection of related web pages. However it is less clear whether other Web services hosted on the same domain, such as the repository at, would also be regarded as part of the coherent set of related web pages. It might be safe to assume that this is the case; in which case accessibility conformance might need to apply to every page (including dynamic pages) hosted under * Therefore, content provided by third-party services, such as embedded YouTube videos, embedded RSS feeds and content included in Web pages using HTML iframe elements, JavaScript and other syndication technologies would also be included.

This represents quite a challenge in ensuring that the content will conform with WCAG 2.0 guidelines! Especially when one considers that the WCAG guidelines are independent of the particular file formats used to host the content; so PDF, MS Word, MS PowerPoint, etc. files which have an institutional URL

Revisiting WCAG 2.0 Guidelines

In order to illustrate the difficulties to be faced in conforming with WCAG 2.0 guidelines, consider the challenges in ensuring full conformance with Principle 3: Understandable – Information and the operation of user interface must be understandable.

On the surface this does not appear unreasonable. The WCAG 2.0 document then provides a more specific guideline: Guideline 3.1 Readable: Make text content readable and understandable. The difficulties start when you see the details:

3.1.4 Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available. (Level AAA)

3.1.6 Pronunciation: A mechanism is available for identifying specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation. (Level AAA)

Yes, in order for an institutional Web site to be conformant with WCAG Level AAA every page, Web pages which contain an abbreviation must provide a mechanism for identifying the expanded form or meaning of abbreviations and for identifying specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation! OK? Or perhaps I should have written “OK (orl korrect)?” as this is one of the possible origins of the abbreviation.

I think it is safe to say that no institution should consider stating that its Web site conforms with WCAG AAA guidelines. But will it be possible for any large-scale Web site to conform fully with all WCAG guidelines, including those which are relevant to WCAG A conformance? I would have thought that any Web site which embeds content from third-party services will not be able to guarantee that the embedded content will be conformant.

Perhaps it is time to move away from stating conformance with WCAG guidelines and, instead, making use of alternative approaches, with BS 8878 providing an approach to consider for those based in the UK. What do you think? Is it realistic to expect that institutional Web sites will be able to conform to WCAG 2.0 guidelines?

Twitter conversation from: [Topsy]

3 Responses to “W3C WAI Invite Feedback on Website Accessibility Conformance Evaluation Methodology 1.0 Working Draft”

  1. Tavis Reddick said

    I agree that it is problematic to claim that a complex website is compliant to a level of WCAG 2.0. Rather than making that claim, an institutional website could describe what they have done and are doing (and aim to do in future) regarding website accessibility.

    So that they might say something like: “This website’s templates have been checked and passed at AA, we monitor and fix any content detected that does not pass AA, and we are working on reaching AAA levels for video lectures, online course applications and the learner support section of our website. We test on [platform list + schedule]. We user-test our online services in rotation every three months with a group of volunteers. Please report any problems or suggestions to webmaster, and you can volunteer for testing (we are particularly looking for users of device X and assistive technology software Y)…”

    If BS 8878 recommends “communicate accessibility decisions at launch”, which seems a best practice, it could be extended to “give a running commentary on web accessibility progress”, perhaps through the website’s blog, or similar.

    By the way, when I used to edit our website, I did put in abbreviation tags with expansions, which I think helps with search and accessibility (screen readers can expand optionally) and also general comprehension, as unknown or ambiguous abbreviations were actually the number one dislike reported at our first user testing session (in those days, I think Firefox but few other browsers showed expansions in tooltips).

  2. […] On Monday 20 September 2012 the W3C WAI published the Website Accessibility Conformance Evaluation Methodology 1.0 working draft.  […]

  3. […] W3C WAI Invite Feedback on Website Accessibility Conformance Evaluation Methodology 1.0 Working&nbsp… […]

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: