UK Web Focus

Innovation and best practices for the Web

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

Posted by Brian Kelly on 8 October 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 public-wai-evaltf@w3.org (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 http://www.bath.ac.uk/ 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 http://opus.bath.ac.uk/, 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 *.bath.ac.uk. 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

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

 
%d bloggers like this: