This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:Accessibility Guidelines Working Group
Other specs in this tool
Accessibility Guidelines Working Group's Issue tracker
Quick access to LC-2819
There are 7 comments (sorted by their types, and the section they are about).
A general comment based on an (admittedly somewhat cursory) read of the rest of this draft of WCAG2ICT.
Insofar as it seems valuable to attempt to apply WCAG 2.0 to ICT generally (I won't dwell on this for now), I think this specific approach, while not without value, largely serves to demonstrate the gulf between abstract generalizations and technical reality as implemented.
At the end of the day: is there enough information here to allow (say) a government agency to craft policies to cover web pages *and* desktop software *and* mobile software *and* electronic documents (PDF, XLSX, etc) *and* ATMs, and and and and….? Or… pick on just documents. Would a Section 508 coordinator be better-informed as to how to implement a "WCAG 2.0 policy" based on this document? Would a software developer have a better understanding of how to invest time in electronic document software development because of WCAG2ICT?
I think those are the questions that I was hoping this document would answer a bit more than it does.
Introduction Paragraph 2:
"This document is intended to help clarify how to use WCAG 2.0"
- Remove the world "help". Either the document does or does not "clarify".
"the needs of people with accessibility requirements due to aging."
- This isn't clearly put. Perhaps "…the needs of people who benefit from accessibility technology due to the effects of aging." or some such.
Intro paragraph 3:
"While WCAG 2.0 was designed to be technology-neutral, it assumes the presence of a “user agent” such as a browser, media player, or assistive technology as a means to access web content."
- You should go on to mention at least some of the other web-specific assumptions (like HTTP) in WCAG 2.0, since they are both directly relevant to the application of WCAG2 to non-web ICT and a proximate cause of confusion over the applicability of WCAG2 to non-web ICT.
"…different contexts of use…"
- Go ahead and say: "non-web technologies".
Intro paragraph 2:
Regarding "Authors and developers are encouraged to seek relevant advice about current best practices…"
- I don't understand why this document avoids mentioning other relevant normative standards for non-Web ICT. There are several such that directly address key areas WCAG2ICT intends to cover, but this draft of WCAG2ICT doesn't even acknowledge their existence. JTC 1, SWG-A should be mentioned here, as should PDF/UA (ISO 14289); both should be added to the References section. PDF/UA should be referenced in the text specifically when discussing documents. I suspect there are other examples as well.
2.4 Set of Documents:
Why are "sets of documents" that are organized by means other than referring to each other or linking not included? I can think of many cases that I don't know how to address based on the definition provided. Some examples that pop immediately to mind...
- A single PDF in which many individual documents have been collated. The sub-documents (if we want to call them that) aren't referenced or linked, but (contra Note 1) they do have semantic significance as a "set" nonetheless because they exist as specific, identifiable, individually targetable (i.e., navigable) pages in a given file. Navigation could occur via bookmarks, scripts, actions, "pages" view (thumbnails)… things not mentioned in WCAG2ICT.
- A PDF with 5 attachments. The attachments are not referenced in the text, nor is a link provided. Is this a "set"? If not, why not? Most UIs would present it as such.
- Multiple PDF files in which bookmarks or actions (not textual references or link annotations) are used to connect one PDF to another (in UI terms).
- An HTML page with links to multiple PDF files - is this an example of a "set of documents"? Does it differ from a set of PDFs deployed together in some other way?
- A PDF in which additional documents (pages or attachments, or rich media annotations) are exposed to the user based on scripting functionality (as opposed to links).
- I take qualifying "set of documents" and republish (bundle) them together into a super-set, thus meeting the conditions for Note 1. Does this mean WCAG2ICT should not apply? Or, does it continue to apply only within each element of the super-set, and not to the super-set itself? Does it matter whether or not the super-set is a "publication" or not?
2.5 Set of Software:
This section appears to have been sculpted in an attempt to (very narrowly) avoid current implementations of popular document authoring products (such as Microsoft Office). Maybe it snags Apache Open Office (because OO can open one app from another without opening an existing document) - I'm not sure. The details about how to construe a "set" seem ambiguous and arbitrary… and most importantly, I cannot determine how the distinctions offered are substantially relevant to accessibility in any nontrivial sense.
Perhaps one way to make this point is to ask: what sets of real-world software *does* this definition include? Is there an example? And if not, then what is the point of such a definition in the first place?
Or, am I to take away the impression that if Microsoft were to be so foolish as to add a feature that would provide for opening Excel from Word without going to the Start menu then all of a sudden their Office suite meets the definition of "set" in WCAG2ICT… and this is worth highlighting? I just don't get it.
Presumably, the practical effect of such a definition will be to cause implementers to avoid X, Y or Z features that might threaten to appear as "a set" while still delivering "suites" (not "sets") of software to users. I read through the usage of "set of software" in the Notes for various Success Criteria and I'm left fairly confused. The text feels very over-engineered. There appear to be nuances and shades of meaning that simply hint at ways to get into trouble. I got very little enhancement to my own understanding from all the sloshing about.
- Counterexamples, 2nd bullet is missing the words "is to" before "open a document".
- Counterexamples, 3rd bullet. How can it possibly matter how the software is *sold*? Isn't it more a question (I guess) of the installation rather than the procurement?
In general the first two paragraphs are very hard to understand. What's the real value here? Why not state it clearly? I would rewrite the first two paras into one, as follows:
WCAG2ICT is not a standard, so it is not possible to conform to WCAG2ICT. However, some entities may wish to use the information in WCAG2ICT to help establish standards or regulations regarding accessibility in ICT that are based on WCAG 2.0. While such standards or regulations will need to address matters of conformance themselves, the following notes may be of assistance to those wishing to draft their own requirements:
Item 1 in the list - Would it not be better to refer to 'levels of compliance" rather than "conformance requirements"? It would seem more in keeping with WCAG 2.0, IMO. Also in the 2nd sentence… change "was" to "is".
Item 2. Is this really necessary? What value does it add?
Item 3 in the list. It's unfortunate that the "i.e." here refers to a web-page - that's precisely what we don't (in principle) need WCAG2ICT to understand. Why not refer to an ATM machine, or a keypad, or whatever?
Item 4 in the list - similar problem to that raised with Item 3 in the parentheticals. C'mon, use a PDF or an ATM machine as an example! Also, the 2nd sentence should begin: "Conformance with WCAG 2.0 requires…."
Item 5 I admire this point - good thinking.
Last paragraph. This is a reasonable re-statement, but I think you should go further to point out that you do not intend a result that would characterize software with a broad brush. After all, if popular product X is fantastically accessible for things that 97% of people care about, but also includes some fancy features used by 3%… maybe those features are non-conforming, but that doesn't really mean the whole application deserves to be tarred and feathered with "Fails WCAG 2.0 (as read via WCAG2ICT)".
Re: WC3 Guidance on Applying WCAG 2.0 to Non-Web ICT: Final Draft
Thank you for the opportunity to provide feedback on the Final Draft. We
appreciate the dedicated hard work of the WCAG2ICT Task Force to develop
To help make this document more useful to a broader audience, we suggest
the addition of a high-level, easy-to-use summary targeted at users who
have little familiarity with WCAG 2.0 requirements and non-web ICT.
We appreciate your consideration of our suggestion.
U.S. Public Policy Council of the Association for Computing Machinery
Add a comment.