Re: Comments on Techniques for WCAG 2.0 and Understanding WCAG 2.0 drafts

================================
Response from the Working Group
================================
Thank you for sending these comments. Our responses appear inline.


Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact


On behalf of the WCAG Working Group

On Mon, Aug 9, 2010 at 2:21 PM, Ian Pouncey <w3c@ipouncey.co.uk> wrote:
> Techniques for WCAG 2.0:
>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#suff-adv-techs
>    1st paragraph addition ('In some cases...') is quite unwieldy. I
> understand what it is saying, but can the wording be more concise?

We have replaced this text with:

Sufficient techniques are provided in a numbered list where each list
item provides the technique or combination of techniques that can be
used to meet the Success Criterion. When there are multiple techniques
on a numbered list item connected by "AND" then all of the techniques
must be used.

For example, Situation B in Understanding Success Criterion 2.2.1
lists as the third sufficient technique:
SCR16: Providing a script that warns the user a time limit is about to
expire (Scripting) AND SCR1: Allowing the user to extend the default
time limit (Scripting)

So both SCR16 and SCR1 must be used to satisfy this success criterion.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#G18-description
>    4th paragraph addition ('For example, if a letter is lighter...'),
> change 'or a thin black outline (at least one pixel wide)' to 'or add
> a thin black outline (at least one pixel wide)'.

We are changing this as proposed.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#G71-procedure
>    2nd point change, drop the word 'help' to leave 'Determine if
> there is at least one link to information explaining how to complete
> the form on this Web page.'

We are changing this as proposed.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#G117-examples
>    I don't think example 1 is as good as it could be. Visual changes
> should not be made using semantic elements unless the meaning matches
> that of the element. Strong emphasis does not mean 'New' unless you
> also want to emphasise that the element _is_ new (and the text makes
> no mention in this change of meaning beyond the visual aspect), and in
> this case wouldn't emphasis (<em>) rather than strong emphasis
> (<strong>) suffice? Also the '(new)' text would be better as part of
> the emphasised text - it is the fact that the item is new that is to
> be brought to the users attention, not specifically the item itself.

In practice, we find that <strong> and <emphasis> are used for a much
wider set of semantics than HTML originally defined. One might argue
that this examples calls for the use of a CSS-style span, rather than
the <strong> element. However, we think the extra complexity of such
an example would distract from the point that visual styling of the
text alone is not sufficient.

We are moving the (New) text inside the <strong> mark-up, as you suggested.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#G181-description
>    The change in the first paragraph is in error and can be removed
> to leave 'data that will be submitted'.

Thank you for catching this. We are correcting the grammatical error
introduced with this edit.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#G182-examples
>    The 3rd paragraph should be changed to read '...so that users who
> have problems distinguishing between colors can identify...'. Unless
> you are from Pingelap the inability to see colour completely is quite
> rare, and even true monochromats can distinguish ~100 colours.

We are changing this as proposed.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#H42-ex1
>    Why are there spaces at the beginning of each element?

We are changing this as proposed.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#H48-ex4
>    Is there a reason for each link to be part of a paragraph?
>    The second set of example CSS is not correctly indented.

Thank you for catching these. We are correcting them as proposed.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#H50-ex2
>    I have never seen this technique used (or even considered for use)
> before, but assuming this works well would the links not be best
> marked up as a list as is usual good practice?

We agree that H48 (Using ol, ul and dl for lists or groups of links)
would be better practice. However, there is evidence that this
technique is accessibility supported and we feel that this should
remain a sufficient technique. (refer to accessibility support data
available from http://accsupported.trace.wisc.edu/use-summary.php?use_id=273)

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#H63-ex1
>    Why wouldn't the first column have a header in this case?

We don't think it would be typical for the visual presentation of such
a table to label the item number with an explicit header.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#H85-ex2
>    Indentation of code is inconsistent.

We are fixing one place where </option> was on its own line, instead
of at the end of the <option> line. Were there other inconsistencies
that you noticed?

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#H92-ex1
>    Add space before '(required)' in <label>.
>    Wrap CSS in <style> element.

We are changing this as proposed.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#C9-ex3
>    Citations are better marked up with <cite> elements.

We are changing this as proposed.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#C15-ex2
>    This example won't work in all major browsers.

The User Agent Notes for this technique lists a number of restrictions
in the support for dynamic pseudo-classes. Are there additional cases
that we should add?

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#SCR35-description
>    I know this document isn't intended to show good practice in
> JavaScript, but do we really have to encourage the propagation of such
> a horrible technique?

We think it is important to document techniques that are known to meet
the requirements of the success criterion.

>
> http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/complete-diff.html#ARIA1-examples
>    More poor quality examples, specifically presentational classes
> (left, right) and inline click handlers, poor performance JavaScript.

We welcome assistance in improving the examples.

>
>
> Understanding WCAG 2.0 drafts:
>
> http://www.w3.org/WAI/GL/2010/WD-UNDERSTANDING-WCAG20-20100708/complete-diff.html#introduction-layers-techs-head
>    1st paragraph addition ('In some cases...') is quite unwieldy. I
> understand what it is saying, but can the wording be more concise?

See our response to your first comment above.

>
> http://www.w3.org/WAI/GL/2010/WD-UNDERSTANDING-WCAG20-20100708/complete-diff.html#visual-audio-contrast-without-color-61-head
>    Change 5th point to 'Users who have problems distinguishing
> between colors...'.
>
>
We are changing this as proposed.

Received on Saturday, 4 September 2010 02:04:09 UTC