W3C home > Mailing lists > Public > public-wcag-em-comments@w3.org > May 2013

Oracle comments on WCAG-EM W3C Working Draft 26 February 2013

From: Peter Korn <peter.korn@oracle.com>
Date: Thu, 16 May 2013 18:19:27 -0700
Message-ID: <5195859F.3060407@oracle.com>
To: public-wcag-em-comments@w3.org
CC: Peter Korn <Peter.Korn@oracle.com>
Dear EvalTF,

While these few comments come to you after the deadline, we hope that it 
may still be possible to consider them in your work.

        Step 2b. "Common Functionality"

The term "Core Functionality" seems a much better choice here. It better 
fits the description: "all functionality of a website that, if removed, 
fundamentally changes the use or purpose of the website for users"

        *Step 4.a: Check for the Broadest Variety of Use Cases*

The second paragraph, starting with the text "To carry out an evaluation 
effectively, it is often useful to construct and apply personas..." 
over-emphasizes a specific approach, particularly with language like the 
second sentence "It is critical to consider...". It should be possible 
to evaluate against WCAG 2.0 on a purely technical, objective basis.  As 
such, this material could be presented as an advisory statement.  As 
written now it goes beyond the scope of WCAG 2.0 conformance.

        Step 4.c: Use Techniques and Failures Where Possible (Optional)

This section appropriately describes the proper use of techniques (that 
they are informative and not mandatory).  However, the document would be 
improved if this were particularly emphasized. We are seeing entities 
that are requiring the use of WCAG 2.0 also requiring the use of these 
techniques as THE way of demonstrating compliance.

      Step 4: Audit the Selected Sample

There was little direction related to web applications related to any 
documentation that may have been provided with the web application, or 
published by the company selling the web app.  For example, the Oracle 
whitepaper Testing Oracle Products for Accessibility 
mentions many things related to the accessibility of web applications, 

  * making sure to read documentation to understand how the product is
    meant to be used, such as keystrokes
  * documentation that might point out workarounds, including
    alternative paths through a website
  * enablement of applicable accessibility modes, if any
  * if using AT, ensuring that a defect found is not in the AT itself,
    and that the user is proficient
  * if using automated test tools, ensuring that it is accurately
    representing the SC and sufficient/failure techniques that it claims
    to meet

        **Step 5.b: Provide a Conformance Evaluation Statement**

While the title uses the phrase "statement", within the body it returns 
to using the word and concept of "conformance", which, as defined by 
WCAG, only exists with perfection.

Also in this section, the note: "*Note:*It is not possible to make an 
accessibility evaluation statement for a website that is still in 
development" appears to ignore the reality that many websites and web 
applications are in "continuous development", and are never finished 
(cf. the long lived "beta" applications from a number of well-known 

        ***5.c: Provide a Performance Score (Optional)*

This is an invitation to consumers of WCAG-EM reports to set a "yes/no" 
bar that is at some specific point below 100% perfection (e.g. a score 
of 95 or higher is required).  Such a move would be of little additional 
improvement to the present situation.  We do not believe this should be 
even a suggested part of WCAG-EM.

Finally, the document in general would benefit from a note mentioning 
some of the potential legal ramifications of using WCAG-EM.  For 
example, if a company creates such a WCAG-EM audit even with the intent 
of correcting the items found, it could be used against them in a court 
of law (such documents can be found in discovery and would likely be 
looked for, even if not published). At a minimum, the document should 
advise anyone performing  this type of work that it would be wise to 
consult legal counsel before starting (this is touched on in the Note at 
the end of 5.a, but really should be called out at the top in more detail).

On behalf of my colleagues at Oracle,


Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522 <tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
Received on Friday, 17 May 2013 01:20:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:41:54 UTC