WCAG 2.0 Public Working Draft: Response to WG Response

Dear Loretta and Working Group members,

Thanks for your comments and the time you and the group have devoted to 
the WCAG 2.0 process. I have responded to each "Response from Working 
Group" below.

Regards,
Sandra.



> 
> ----------------------------------------------------------
> Comment 1: Guideline does not mention the need for equivalent
> alternatives (only SC).
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0266.html
> (Issue ID: 2096)
> ----------------------------
> Original Comment:
> ----------------------------
> 
> As stated by the Guideline, the primary benefit in providing text
> alternatives for any non-text content is that it can be changed into
> other forms people need such as large print, braille, speech, symbols
> or simpler language. However, unless the alternative conveys the same
> information it may be of little use.
> 
> Courts and Government policy makers will most likely use the W3C
> normative guidelines as their benchmark for determinations of
> accessibility conformance and since the Success Criterion 1.1.1
> (Non-text Content) already has as a checkpoint that "All non-text
> content has a text alternative that presents equivalent information
> ...", it would be beneficial and consistent to include equivalence in
> the actual Guideline.
> 
> Proposed Change:
> Edit Guideline 1.1 to read "Provide equivalent text alternatives for
> any non-text content so that it can be changed into other forms people
> need such as large print, braille, speech, symbols or simpler
> language"
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> We did have equivalent in there at one point. But not all of the text
> alternatives are equivalent. In some cases it is impossible for the
> text alternative to be equivalent. There are a number of text
> alternatives that label content. Thus, the guideline was changed to
> match this situation. The different points under SC 1.1.1 explain the
> different situations in which equivalent text alternatives are
> required vs when a label is deemed sufficient.
> 

--------------------------------
Response to response
--------------------------------

Thanks Loretta. I note that SC 1.1.1 and related SC for Guidelines 4.1 &
1.2 are Level A and that "all Level A success criteria must be satisfied
in order to achieve A (single-A) conformance". My main concern was to 
clarify that text equivalents need to meaningful, as so often they are not.

I also noticed in the "Understanding WCAG 2.0" document "Techniques for
Addressing Success Criterion 1.1.1" there was mention of additional
requirements using "AND" where "a short description can not serve the
same purpose or present the same information as the non-text content".
However, there does not appear to be any additional requirement for
multimedia where a short description is not sufficient.

If it is not possible to include "equivalent" in the wording of the
actual Guideline then perhaps (something like) the following could be
added to the  Sufficient Techniques for multimedia in 1.1.1 (e.g. 
Situation B) ...

AND providing a transcript AND/OR providing synchronized alternatives 
for multimedia (Guideline 1.2)

PS: I have grappled with this and recognise it is a difficult area (and 
one being actively debated even within the accesibility community) due 
to the significant benefit of this medium to some people with disability 
balanced against the resource intensiveness of creating accessible 
alternatives for multimedia at present. If possible I would like to find 
a way to acknowledge that for a multimedia site to be fully accessible 
equivalent alternatives for multimedia are required (with exceptions if 
appropriate e.g. a test or exercise that must use a particular sense) 
and my feeling was that the techniques area provides this opportunity. 
Not having this provision implies sites can be accessible without it and 
while the technology is not fully developed now to easily create 
transcripts or synchronized alternatives on the fly, it may be in the 
future (plus the WCAG 2.0 guidelines are not technology dependent). For 
situations where this does present undue hardship there is also 
provision in the DDA law (in Australia) for further consideration to be 
taken into account. To my knowledge, similar mechanisms, such as undue 
burden or undue hardship, also exist in most other jurisdictions where 
disability discrimination legislation is in place.




> ----------------------------------------------------------
> Comment 2: Add definition of testability to Guidelines (Introduction & Glossary)
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0269.html
> (Issue ID: 2099)
> ----------------------------
> Original Comment:
> ----------------------------
> 
> There needs to be a clear definition of testability in the
> Introduction and Glossary of the Guidelines so that it is understood
> that this refers to both machine and human testable measures.
> 
> Testability is a core premise of the new WCAG 2.0, which I understand
> to embrace both machine and/or human testability, although this is not
> clearly documented in the normative guidelines. The human testable
> aspect of this definition is critical to certain guidelines being
> effectively implemented e.g. testing for equivalent text alternatives
> to non-text content. My concern is that many developers will see
> testability as a purely automated validation and when this is passed
> for presence of alt text it will be considered sufficient even if were
> not considered equivalent by human testers.
> 
> 
> 
> Proposed Change:
> Include the definitions for testable (currently provided in the
> "Requirements for WCAG 2.0 Checklists and Techniques" document at
> www.w3.org/TR/2003/WD-wcag2-tech-req-20030207/#defs) in the normative
> Guidelines Glossary and mention in the Introduction that testability
> includes both machine and human testable criteria. This second point
> could be achieved by editing the second paragraph in the Introduction:
> 
> "Rather than specifying what technologies to use, WCAG 2.0 lays out
> general guidelines for using technologies along with specific machine
> and human testable success criteria for guiding and evaluating the use
> of the technologies."
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> We have added your language to the introduction.  We have not defined
> testability since we are using it in the normal English language sense
> of the word.   We do discuss its meaning however in the Conformance
> section of the guidelines.

--------------------------------
Response to response
--------------------------------

Thanks.



> 
> ----------------------------------------------------------
> Comment 3: Skip links are not required to be visible (G1)
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0270.html
> (Issue ID: 2100)
> ----------------------------
> Original Comment:
> ----------------------------
> 
> The techniques document currently includes appropriate rationale i.e.
> "visible links are necessary for those navigating with a keyboard
> including switch users, those using techniques that generate keyboard
> strokes slowly, screen magnification software users, screen reader
> users working with sighted colleagues, keyboard only users and those
> navigating using voice recognition software". However the preceding
> sentence "when possible, a visible link is preferred over a hidden
> link" seems to contradict the importance of this.
> 
> Proposed Change:
> 
> Change "when possible ..." to read "skip links are required to be
> visible, not hidden, at least on keyboard focus."
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> We have updated the sufficient techniques related to skip navigation
> links to include a requirement that the links either be always visible
> or visible when they have keyboard focus. We have also removed the
> sentence, "When possible, a visible link is preferred over a hidden
> link."
> 

--------------------------------
Response to response
--------------------------------


Thanks.


> ----------------------------------------------------------
> Comment 4: Stronger statement about accessibility for people with
> cognitive disability
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0271.html
> (Issue ID: 2101)
> Status: VERIFIED ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> In their current form there are still some important areas of web
> accessibility for people with cognitive, language, and learning
> disability that are not covered by the WCAG 2.0 Guidelines and due to
> testability are unlikely to be accepted.
> 
> With this in mind a stronger statement about the importance of web
> accessibility for this audience and the need for developers to
> consider issues affecting these users would be worthwhile.
> 
> The first part of this issue has already been taken up in the recent
> draft, which states:
> 
> "Although some of the accessibility issues of people with cognitive,
> language, and learning disabilities are addressed by WCAG 2.0, either
> directly or through assistive technologies, the WCAG 2.0 guidelines do
> not address many areas of need for people with these disabilities.
> There is a need for more research and development in this important
> area." (WCAG 2.0 Introduction)
> 
> In addition a statement that encourages developers to follow current
> best practice for this group as part of meeting their accessibility
> obligations would help raise awareness and provide support for any
> companion documents/checklists that may be developed by authoritative
> agencies in the future.
> 
> Proposed Change:
> 
> Add the following recommendation to the end of the existing paragraph
> in the WCAG 2.0 Guidelines:
> 
> "... There is a need for more research and development in this
> important area and developers should seek relevant expert advice about
> current best practice to ensure that web content is accessible, as far
> as possible, to this community."
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> The Working Group hoped that the inclusion of the sentence "There is a
> need for more research and development in this important area." would
> encourage support in the research community for additional work in
> these areas.  At the request of several reviewers, we have removed it.
> 
> We added the sentence based on comments submitted:
> 
> Authors are encouraged to consider the full range of techniques,
> including the advisory techniques, as well as to seek relevant advice
> about current best practice to ensure that Web content is accessible,
> as far as possible, to this community. Metadata may assist users in
> finding content most suitable for their needs.
> 
> 
> In context it reads:
> 
> All of these layers of guidance (guidelines, success criteria, and
> sufficient and advisory techniques) work together to provide guidance
> on how to make content more accessible. Authors are encouraged to view
> and apply all layers that they are able to, including the advisory
> techniques, in order to best address the needs of the widest possible
> range of users.
> 
> Note that even content that conforms at the highest level (AAA) will
> not be accessible to individuals with all types, degrees, or
> combinations of disability particularly in the cognitive language and
> learning areas. Authors are encouraged to consider the full range of
> techniques, including the advisory techniques, as well as to seek
> relevant advice about current best practice to ensure that Web content
> is accessible, as far as possible, to this community. Metadata may
> assist users in finding content most suitable for their needs.

--------------------------------
Response to response
--------------------------------

The rewording above is appreciated.

Since submitting these comments I've continued to look for a way to
include the qualitative aspects of usability/accessibility testing and
user testing that are so important to accessibility for people with
cognitive disability.

My current thinking is that accessibility to date has relied on a mix of
qualitative and quantitative testing, automated and manual checks as
well as user testing by people with disability.

It seems some of the SC are moving in this direction and if it is
possible to do this for some criteria (e.g. SC 1.1.1) then perhaps it
could be done for others too.

If this is not possible, and the scope of WCAG 2.0 is that Guidelines
must be testable, then it would be very valuable to acknowledge that
testability is only one part of the accessibility process, so that due
recognition is given to the qualitative accessibility criteria and most
especially to user testing by people with disability as part of a
comprehensive web content accessibility process.

For example, a statement, (following or near "WCAG 2.0 success criteria
are written as testable statements that are not technology-specific" in
the introduction), to the effect that WCAG 2.0 provides a checklist of
quantitative machine/human testable guidelines that can be validated for
conformance. In addition, professional reviews utilising recognised
qualitative heuristics are important in achieving accessibility for some
audiences. There is also no real substitute for user testing, and
designers should, wherever possible, involve users of assistive
technology in the testing and evaluation of the accessibility of their
websites.

The last part of this sentence is quoted from the "World Wide Web
Access: Disability Discrimination Act Advisory Notes" Version 3.2
August 2002, published by the Human Rights and Equal Opportunity
Commission at www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html




> 
> ----------------------------------------------------------
> Comment 5: Clarification on Conformance Requirements for Alternative Content
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0280.html
> (Issue ID: 2110)
> ----------------------------
> Original Comment:
> ----------------------------
> 
> The option to accept an alternative accessible page has merit but is
> also a significant weakness and I am nervous that this may be used by
> some websites as a way to legitimately avoid any efforts involved in
> making the primary content accessible. The legacy of "text only" links
> as the accessibility solution to HTML 3.2 is only just being redressed
> and WCAG 2.0 seems to open the possibility for this to start all over
> again with a proliferation of "alternate" pages. This approach treats
> people with disability as a separate audience, rather than
> acknowledging them as part of the diversity in every audience (i.e.
> children with disability, job seekers with disability, seniors with
> disability, employer with disability).
> 
> In its current form this requirement appears to make it acceptable for
> software developers to release and re-release versions of their
> product with no priority or time frame for including accessibility but
> to still be used on accessible websites and have the status of
> conforming to the level of the accessible alternate page.
> 
> In a commercial world there are many competing demands for time and
> resources with the result that accessibility is often seen as a lower
> priority. Once it is acceptable for developers to publish alternate
> content pages then championing mainstream accessibility becomes
> harder, especially when this approach is endorsed by an international
> body with the standing of the W3C. As such, I suspect accessibility
> considerations will have less chance of competing with other important
> business requirements.
> 
> Similarly, once alternate pages are published there is little
> incentive in the Guidelines for developers to make the main pages
> accessible in the future and in practice (unless they are drawn from
> single sourced content) alternate pages are infrequently, if ever,
> updated. For example, there is no requirement (I could see) to make
> the main web page accessible if it becomes possible to do this with
> the software at a later date or for people to make it accessible if it
> is possible but harder to implement using the software accessibility
> properties. Currently "If the Web page does not meet all of the
> success criteria for a specified level, then a mechanism to obtain an
> alternate version that meets all of the success criteria can be
> derived from the nonconforming content" is acceptable.
> 
> Getting to the accessible content in an accessible way from an
> inaccessible page is also an unresolved issue at present (as
> documented in the WCAG 2.0 Editorial Note) and I'm wondering why the
> focus is not on universal design with progressive enhancement for
> inaccessible formats, starting with the accessible document as the
> main/default page.
> 
> Note: I have not had time to fully explore all the WCAG 2.0
> documentation in the time available for comments, so please let me
> know if this concern is already addressed. However, from my reading so
> far it seems to be rather a big issue that is not yet satisfactorily
> resolved – in that websites can claim conformance in principle while
> not conforming in spirit to the Guidelines.
> 
> 
> 
> Proposed Change:
> This needs more thought than I've had time to give it at present, but
> possible changes might include:
> 
> * a statement to the effect that if it is possible for the main
> content to be made accessible then an alternate page is not acceptable
> 
> * making the most accessible page the main/default page with links to
> or progressive enhancement of inaccessible content
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> We have added a note to say "Alternate versions may be provided to
> accommodate different technology environments or user groups. Each
> version should be as conformant as possible. One version must be fully
> conformant in order to meet conformance requirement 1."
> 

--------------------------------
Response to response
--------------------------------


Thanks, although the note does not seem to address the consideration of 
accessing the accessible alternative. It would be good to include this 
in the note, for example ...

"Alternate versions may be provided to accommodate different technology 
environments or user groups. One version must be fully conformant in 
order to meet conformance requirement 1. Easy access to the accessible 
content in an accessible way and ahead of any inaccessible content is 
also required. Each version should be as conformant as possible."




> ----------------------------------------------------------
> Comment 6: Text resizing - What Level
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0281.html
> (Issue ID: 2111)
> ----------------------------
> Original Comment:
> ----------------------------
> 
> The ability to resize text can be critical to accessibility for people
> with print disabilities such as degenerative eye sight and
> reading/learning difficulty but this does not seem to be adequately
> covered in the Guidelines.
> 
> 1. SC 1.4.4 Resize Text is a Level AA requirement (rather than Level A)
> 
> 2. Text as an image appears to be acceptable, yet images are not
> resizable by many browsers and where image "zoom" is a feature of
> the browser this can create other accessibility problems such as
> broken page formats, horizontal scroll bars and pixelation of the
> text/image. Turning images off to view the alt text is not a practical
> solution, since many people do not know how to do this and once set
> this preference applies to all images not just text images. It becomes
> increasingly difficult when text based images are used for navigation
> elements, such as an image map.
> 
> 3. Resizing of text based form content and form controls also does not
> seem to be mentioned and textual content in non-text based form
> controls also needs to be resizable by the user. For example: using
> the browser resizing options in forms is problematic when the text
> resizes but not the radio button.
> 
> Proposed Change:
> 1. Move SC 1.4.4 to Level A
> 
> 2. Text as an image should not be acceptable unless Success Criterion
> are applied that would address the needs of people with print
> disability
> 
> 3. Include Success Criterion for resizing of text based and non-text
> based form controls
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> RE # 1. Move SC 1.4.4 to Level A
> 
> This provision may not be implementable with some technologies
> directly but the same effect could be achieved with assistive
> technologies.   Because of these factors the Working Group feels that
> his provision is better put at Level AA.  The working group examined
> the issue of images of text carefully and felt that they should be
> allowed,.
> 
> The group feels that the majority of images of text used on the web
> these day can be zoomed up to 200% and down to 50% without pixelation
> being a significant barrier. For zooming above that AT have smoothing
> algorithms. The group also feels that there are sufficient resources
> in the operating system and with external AT devices that contrast
> issues can be handled at level AA. However, we have made a note in the
> understanding document describing some of the problems with images of
> text such as contrast and pixelation, and we encourage text. And we
> have added a note to 1.4.3.
> 
> For 1.4.3: Note: Images of text do not scale as well as text because
> they tend to pixelate. It is also harder to change foreground and
> background contrast and color combinations for images of text, which
> is necessary for some users. Therefore, we suggest using text wherever
> possible, and when not, consider supplying an image of higher
> resolution.
> 
> For 1.4.4: Note: Images of text do not scale as well as text because
> they tend to pixelate, and therefore we suggest using text wherever
> possible. It is also harder to change foreground and background
> contrast and color combinations for images of text, which are
> necessary for some users.
> 
> RE #3 Include Success Criterion for resizing of text based and
> non-text based form controls
> 
> We think this should be a User Agent guideline, and just an
> advisory/repair  technique in WCAG. If text is big enough to be
> useful, it will be so big that designers won't want to use it. If some
> elements scale and others don't, the layout is likely to get messed
> up.  Whether that's a barrier or not depends on whether content or
> functionality is lost, but it's much eaiser to get this right when
> everything scales such as a user agent zoom, commercial AT, or
> operating system magnification. However we have added a sufficient
> technique for 1.4.4: "Specifying the size of objects in terms of the
> font size"
> 
> By the time WCAG reaches recommendation, we expect Zoom features in
> browsers will become more and more used among people who need moderate
> amounts of zoom. We realize that this is not perfect, but we think it
> is the best compromise given the alternatives.
> 


--------------------------------
Response to response
--------------------------------

Thanks for the time the WG put into reviewing this. I still feel that 
this should be a Level A requirement, not least because of the aging 
population. However, if it is to remain at Level AA then it would be 
helpful to include the WG rational above as part of the requirement for 
accessibility, since this provides a measurable benchmark for legibility 
of images used ie that they can be zoomed up to 200% and down to 50% 
without pixelation affecting readability.

Received on Monday, 19 November 2007 06:17:01 UTC