Message received – introducing WCAG-EM and WAI-Engage

Error message

Deprecated function: Array and string offset access syntax with curly braces is deprecated in include_once() (line 14 of /home/mediacc/public_html/themes/engines/phptemplate/phptemplate.engine).

One of my roles at Media Access Australia is the co-teaching of a six week online web accessibility course with Dr Denise Wood at the University of South Australia. One of the most common requests from students is for some sort of definitive guide as to how to effectively evaluate the accessibility of a website. Another common topic, discussed in last month’s column, is the challenges faced by newcomers to accessibility and the need for some sort of collaborative community group.

Two new announcements from the W3C WAI are therefore very welcome, as they address both of these needs: the Website Accessibility Conformance Evaluation Methodology (WCAG-EM)and WAI-Engage.

WCAG-EM

WCAG-EM is produced by the collaborative efforts of the WCAG 2.0 Evaluation Methodology Task Force (Eval TF), a joint task force of the Web Content Accessibility Guidelines Working Group (WCAG WG)and Evaluation and Repair Tools Working Group (ERT WG).

It aims to create an internationally harmonised methodology for evaluating the accessibility conformance of websites to WCAG 2.0. It defines an approach for conformance evaluation in different contexts, including self-assessment and third-party evaluation. The idea is to make a methodology that is applicable to any website regardless of the evaluation tool, web browser or assistive technology that is being used.

The evaluation methodology is described as a five-step process:
 

1.    Define the evaluation scope

2.    Explore the target website

3.    Select a representative sample

4.    Audit the selected sample

5.    Report the evaluation findings

This process is similar to one a lot of website evaluators already follow: set some definitions as to what level of WCAG 2.0 is being tested and what tools are going to be used get a feel for the website, test a sample of the website and create an audit report. 

Recently I participated in a meeting where a number of web practitioners were discussing the merits of WCAG-EM. There was a lot of excitement around the table at the idea that the W3C was now in the business of providing guidance in this area: while auditing a website based on WCAG 2.0 was generally what people requested of accessibility specialists, each person had developed their own system for performing such checks, and from their point of view it would be helpful to demonstrate to clients that their evaluations followed both the W3C guidelines and the W3C evaluation method.

The initial response to the first three steps was fairly positive:  the methodology for step one recommends identifying the scope of the website, evaluation goal, conformance target, context of website use and the optional defining of the techniques to be used in the evaluation.  For most practitioners this was very similar to their existing processes and they thought it was a well-structured approach. 

Step two was seen as being highly beneficial as it had often been difficult to have a uniform process for identifying the key web pages, functionalities, types and technologies and it was believed this would provide great guidance as the draft continued to be developed. Likewise the selection of the sample pages in the third step had the potential to be a very clear and uniform process.

 

However, the group were concerned about step four. Many were hoping that this section would provide guidance as to how to procedurally audit a website: the specific steps in applying an evaluation tool and testing assistive technologies, and which elements should be emphasised. Given that an evaluation tool can only test a certain number of elements, and using a screen reader can only test a certain number of elements, the developers at the meeting were hoping there might be some guidance by the W3C as to which test should be done first, which WCAG guidelines should apply to which tests, and which techniques are the most efficient in quickly identifying accessibility issues.  

As the step currently stands, it talks about use cases, using WCAG 2.0 techniques, accessibility support techniques and the optional archiving of web pages for reference. While the group indicated this was helpful, there is very little information on these at this stage and no-one was sure how they could follow the method in the context of their work. 

Step five was also raised as having some concerns due to the optional nature of presenting ways to fix the accessibility issues.  There was further uncertainty about a performance score, and how this could be calculated.

While many of these concerns raise some valid points in my view, it’s also important to note this is the first draft of what is likely to be an extensive evaluation and revision process. 

I suspect that WCAG-EM will follow a similar path to WCAG 2.0 in that there may be a top-level Guidelines document available which is complemented by a techniques document that is more of an ongoing process. 

In my humble opinion WCAG-EM is off to a good start and if it achieves its goal it will be significant in addressing one of the biggest issues faced by web practitioners: verifying the conformance of a website.

Although public participation has closed for the moment, there will be plenty of opportunities in the future to put your views forward.

WAI-Engage

It’s amazing just how quickly good ideas can sometimes come to life. 

After last month’s column a perceived enthusiasm for simplifying the accessibility message and generating community involvement, Jennison Asuncion has just kick-started a group called WAI-Engage. 

This is an “open forum for responsive development of material supporting web accessibility”, including support for WAI resources. WAI-Engage is different to just about any other WAI group due to the fact that anyone can sign up regardless of their technical knowledge and there is no specific time commitment or experience expected.

It also uses wikis to develop and share ideas across accessibility so there’s lots of opportunity to get involved. If you’ve ever wanted to make a contribution to WAI but found the technical nature of the working groups a bit daunting, it’s definitely worth having a look. 

Hopefully, this will be the beginning of a simpler gateway for people of all backgrounds to engage in supporting the online needs of people with disabilities.

Other W3C WAI news

ATAG 2.0: WAI encourages developers of web authoring tools (content management systems, HTML editors, social networking apps, and more) to start using Authoring Tool Accessibility Guidelines ATAG 2.0Working Draft. It's now in the Last CallWorking Draft stage, so if you’d like to make a contribution, you can do so until 5 June 2012.

Mobile accessibility symposium: The Research and Development Working Group (RDWG)will hold an online symposium to explore mobile accessibility challenges, existing resources, and areas for future research and development. The Call for Papersis open for one more week, closing on the 7 May 2012.

Dr Scott Hollier represents Media Access Australia on the W3C Advisory Committee and publishes the W3C Column monthly.


Top of page
Tags: Web