WCAG-EM comments. Section 2 Using this methodology

Dear Eval TF,

Please find below more comments for the WCAG-EM Working Draft dated 20 
September 2012.

As in my previous comments, please apologise if something has been 
already discussed (indeed, I've seen some "answers" to my previous 
comments while reading this new section).


Section 2. Using this Methodology

2.1 Scope of applicability

"full, self-enclosed websites"

The "self-enclosed" part can be important under certain situations and 
is not included in the definition of "website" in section 1.4. Current 
definition is: "A 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."

With this definition (and without the "self-enclosed" part), a website 
can also be an embedded collection of web pages within a native mobile 
app or other similar environment (TV/ATM...). Sometimes this might 
create a conflict between the evaluation of the "native" part and the 
evaluation of the "website" part (for example, the embedded website 
might not need page titles, navigation, etc.).



Examples of websites

I would include other common types of websites (and others that are not 
so common) such as:

- "The extranet for the online tax payment system of Public 
Administration X"

- "The tablet version of the collaborative web game..."

- "Version 3.1 of the Word processing and File sharing tool..."

Of course, it is better to keep the number of examples low, but it's 
also good to show a wider range of "non-typical" use cases.



"Full websites" and excluding parts / pages

Maybe this is better explained later in the methodology, but for now my 
impression reading this is that the methodology will lead to mark a 
website as "inaccessible" only because some parts are not fully 
accessible, and I think this is not desirable. (I assume that I have to 
read the "Reporting" part, but I'm reading this section as a first-time 
reader).

It is stated that "excluding parts of the website would likely conflict 
with the WCAG 2.0 conformance requirements full pages and complete 
processes, or significantly distort the evaluation results".

I don't see any conflict if certain "pages" (or even processes) are 
excluded. Component #4 of the "Required Components of a Conformance 
Claim" does not prohibit exclusions, and a "concise description of the 
Web pages" could be something like "All Web pages under mydomain.com 
except PDF documents older than...".

Indeed, there are multiple situations where clients cannot assume the 
necessary changes to "completely conform in all pages", and where the 
only "solution" is to explicitly state that there are parts of the 
website that are not accessible.

For example, we can have a website that contains a high number of very 
old PDF's (and that are not likely be used by anyone). This is more or 
less frequent with Public Administration websites.

In this case it is not realistic to consider their accessibility as a 
requirement for conformance. Instead, the Conformance Claim can say 
something like "only the PDF's created after this Conformance Claim are 
developed in an accessible way. Older PDF's are provided in a 
non-accessible format. If you want an accessible version of a particular 
PDF file, please send a request to ...". In this cases, we cannot simply 
tell our client: "you have to modify your PDF's if you want to conform 
according to this methodology". Moreover, even if they are created with 
accessibility criteria, PDF's can be consideren inaccessible if the 
context of use includes MacOS X or Linux. Thus, I consider more 
realistic to inform about the exclusion than prohibiting exclusions.

Other similar situations could be:

- Photo/video galleries where it is not possible to describe each photo 
or include subtitles/audiodescription.

- A complementary mapping service that adds functionality to the basic 
information provided in the website. The website would have simple 
information such as addresses or even directions, and also a link to the 
map/street view in a secondary page. Although it could be argued that 
the "inaccessible map" has its "accessible equivalent" in the address, 
some evaluators could consider this as a failure and conclude that the 
full website should be "marked as inaccessible".

- An online library with book reviews and other information, that offers 
also scanned versions of the books (or parts of the books). There is no 
separate section for the scanned versions, so in this case it is not 
possible to evaluate separate sections as different websites.

- Real-time processes or other things that cannot be made accessible. 
Even if there are some exceptions for real-time and so on, it could 
happen that a single non-conformant page would distort the overall 
accessibility.


In my opinion, this kind of situations do not mean that the website as a 
whole is not accessible, and telling that in a "overall result" would 
probably discourage the website owner from adopting accessibility 
criteria for the rest of the website.

I also think the Conformance Claim section in WCAG 2.0 is clearly open 
to allow exclusions, and if we already know that some parts will be 
inaccessible, we should be able to define the exact scope of the 
evaluation without being forced to include ALL the pages. I think we 
should maintain this openness in WCAG-EM; if we close the possibility 
for exclusions, I see a potential risk that the methodology itself would 
not be adopted by website owners with these special needs related to 
non-conformant parts.


(Ed) In the graphic "Example of a Website", avoid using transparency for 
the background colour of text and shapes. In high contrast mode the 
graphic is not legible.


(Ed) There is a missed "be" in the sentence: "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". It should say "if it is to BE applied..."



2.1.1 Particular types of websites

"Web Applications"

Ok, now I see the approach that you adopted to my previous concerns 
about Single-Page apps...

(Ed) In the definition of "Web Application", I think that the last 
sentence lacks a verb in the middle... Now it reads: "Each state 
(individual representation of content and functionality) in which such a 
web application can be [is?] considered to be a web page for the purpose 
of this document". I would change the order of the sentence: "For the 
purpose of this document, the definition of 'Web page' is extended to 
include each state (individual representation of content and 
functionality) in which such a web application can be". And maybe I 
would change the parenthesis "each individual representation of content 
and functionality (state) in which such".

Even with this grammar, I don't like very much the term "state", since 
it can be confused with the "states" used in SC 4.1.2 Name, Role, Value 
(example: activating a checkbox generates another state; is this a new 
web page?). I suppose that the intention is to maintain "Web page" as 
the only reference term for the sampling process, but I'd probably 
prefer separate instructions for "sampling pages", "sampling processes" 
and "sampling functionalities" than using this kind of artificial 
definitions of "Web page".

In any case, it would be good to include examples of "Web pages" that 
consist of "states", now it sounds really theoretical and confusing.


"Websites in Multiple Versions"

What about Responsive Web Design? Sometimes responsive web pages can be 
really different depending on the context/device/zoom factor. For 
example, RWD can be used to provide different UX when the user increases 
text size. I think that we should include a "Responsive Websites" case 
and maybe include also specific information for sampling or testing (for 
example, evaluating SC 1.4.4 would require a very different approach).


Other types of websites

I would also add other types of websites, or explicitly exclude some 
types of websites that cannot be evaluated with WCAG-EM (in this case 
the introduction would have to be changed):

- Websites embedded within Native mobile apps (already explained)

- Mobile apps developed using web technologies such as HTML5, CSS3 and 
JS (maybe this is just another example for the "Examples of websites" 
section).

- Websites used in TV/game consoles/ATM that are embedded within 
specific environments (that is, we will not have to evaluate their 
environment, only the embedded website). This is similar to the above 
"embedded within a mobile app" case, but in this case we will likely not 
have control over the enclosing environment. Maybe we can just consider 
the "environments" as "user agents"...

- Websites that are created for a specific group of people with 
disabilities (blind users, deaf users...) or for specific purposes that 
are not intended to be accessible to all types of disabilities (although 
it is likely that WCAG 2.0 itself is not applicable to them as it is). 
An example of this could be an online course for driving a car; it makes 
no sense to pretend "accessibility for the blind users", but it can be 
suitable for a user with motor disability.



2.3 Evaluation Tools

(Ed) In the note about accessibility evaluation tools, it says "testing 
accessibility requirements...". Since "requirements" is used in WCAG 2.0 
for the "Conformance Requirements", I think it would be better to use 
"criteria" (the "testable" part of WCAG).



2.4 Review Teams

(Ed) Maybe it is me, but "review" sounds like "someone evaluates and 
someone else reviews". Maybe it's better to say "Teams of Evaluators" or 
a similar expression.



2.5 Involving users

(Ed) Now it says: "accessibility barriers that are not easily 
discovered". It also depends on expertise, so I would change it by 
"accessibility barriers that might not be easily discovered".


To be continued... (smile)

Regards,
Ramón.

Received on Monday, 1 October 2012 22:17:59 UTC