Disposition of comments for the Accessibility Guidelines Working Group

Understanding SC 2.4.8 at
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-location.html

Problem:
The existing set of techniques could include the page title (G88) as a
sufficient / advisory technique.

Proposed Change:
Using page title also serves to orient users on their location. Use G88:
Providing descriptive titles for Web pages
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G88 as a sufficient
technique under SC 2.4.8. If the editors feel that the length of the page
title string cannot be accommodated in the title bar, consider using this
as an advisory.

-Devarshi

Name: Alastair Campbell
Email: alastc@gmail.com
Affiliation: Nomensa
Document: UW
Item Number: Understanding Success Criterion 1.4.4
Part of Item: Sufficient Techniques
Comment Type: general comment
Summary of Issue: Allowing for Responsive Design methods
Comment (Including rationale for any proposed change):
Since WCAG 2 was published there have been two major shifts that affect re-sizing things in (desktop) browsers:

1. All desktop browsers now default to zoom, where zooming expands everything on the page. A browser at 1024px wide would report a width of 512px at 200%.

2. Responsive design (where sites re-size based on the reported width of the browser) is becoming popular.

These two methods combined actually work very well for zooming.

I think we should update the understanding page and sufficient techniques to allow for (perhaps even encourage) responsive design techniques.

More explanation and discussion here:
http://alastairc.ac/2013/08/browser-zoom-great-for-accessibility/

Proposed Change:
Overall, I think there should now be two sufficient tests/methods to pass:

1. Zoom to 200% with no horizontal scrolling or loss of content / functionality.
2. Text-sizing to 200% without loosing content / functionality.

Specific points on the text:
- Encourage the use of techniques that work with user-agents, rather than suggesting developers build in text-resizing widgets (paragraph 2).

- Remove references to old/defunct browsers such as IE6 (and Firefox also defaults to zoom now) in paragraph 3.

- In the 'working group feels' paragraph, state that using media queries should be used to manage the layout of pages at higher zoom levels.

In the third example of success criterion:
- "A user uses a zoom function in his user agent to change the scale of the content. All the content scales uniformly, and the media queries used on the site prevent horizontal scrolling."

It would also be good to add a sufficient technique for responsive design.

NB: I am happy to draft a new version of the page and add a technique, I just saw the deadline for the call for comments and wanted to get this in quickly.

*Focus Visible*: Understanding SC 2.4.7

[Begin add]

If there is only one keyboard actionable control on the screen, the success
criterion would be met because the visual design presents only one keyboard
actionable item.

[End add]

Comment: If there is no visible focus on the page, how would someone know
that only one item was actionable? If the only actionable item was a
custom edit field, how would a person properly edit text if there was no
blinking caret? Adding this exception creates a loop hole that allows for
inaccessible content. Please do not add this item.

*Labels or Instructions*:
Understanding SC 3.3.2

[begin add]

*Note: *If labels are provided, the label relationship to the object
labeled must be programmatically determined or described in text per
*Understanding
Success Criterion 1.3.1 Info and
Relationships<http://www.w3.org/WAI/GL/2013/WD-UNDERSTANDING-WCAG20-20130711/complete-diff.html#content-structure-separation-programmatic>
*.

[end add]



Comment: This addition implies that the label must be programmatically
associated when a label is used. It is possible that a visual label might
be present in addition to a title attribute or use of aria-label thus
removing the need for an explicitly associated label. The problematic text
“the label relationship to the object labeled must be programmatically
determined” should be changed to say “a label with the same text must be
programmatically determinable”.

Dear WCAG WG,

EOWG considered the placement of the Note that starts out "Note 1: W3C cautions against requiring..." in Understanding Techniques for WCAG Success Criteria <http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/understanding-techniques.html> There were conflicting perspectives, and no one felt strongly enough to try to convince others in EOWG to come up with a consensus position. We therefore submit the perspectives below for your consideration.

Regards,
Shawn for EOWG


<p><a href="http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/understanding-techniques.html">Understanding Techniques for WCAG Success Criteria</a> has a note that starts out: &quot;Note 1: W3C cautions against requiring...&quot;
It's an important point and we want to make sure people read it. Currently it is in the <a href="http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/understanding-techniques.html#ut-understanding-techniques-informative-head">Techniques are Informative</a> section. Some think it would be better in the <a href="http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/understanding-techniques.html#ut-understanding-techniques-sufficient-head">Sufficient Techniques</a> section (right before the heading &quot;Numbered Lists, &quot;AND&quot;&quot;). Thoughts? </p>
<ul>
<li style="margin-top: 1em;">I'm one who thinks it wouod be better in the Sufficient Techniques section - they're what we're referring to <span style="color:#808080;">{Andrew, 2/Aug}</span></li>
<li style="margin-top: 1em;">I agree with Andrew, it would be easier to read in the &quot;suffiscient techniques&quot; section. <span style="color:#808080;">{Sylvie}</span></li>
<li style="margin-top: 1em;">I feel that it belongs in the &quot;Techniques are Informative&quot; section because it's <strong>broadly about not requiring the Techniques</strong>, rather than specifically about the sufficient techniques. (although I'm not set on this) <span style="color:#808080;">{Shawn}</span></li>
<li style="margin-top: 1em;">I feel that it would sit better under the Sufficient Techniques section and most naturally just before the para starting &quot;There may be other ways ...&quot; and without being marked as a note. <span style="color:#808080;">{Bim, Aug 2}</span></li>
<li style="margin-top: 1em;">I agree with Shawn, but it may be useful to add a reminder on Sufficient Techniques section.<span style="color:#808080;">{Emmanuelle}</span> <br />
The Sufficient Techniques section currently has &quot;(See also Techniques are Informative above.)&quot; so it generally points to that section, though not specifically to that note.</li>
<li style="margin-top: 1em;">I also agree that the information would be best if it was in the &quot;Sufficient Techniques&quot; section. Can we duplicate the info? I believe it wouldn't hurt to also mention it in the &quot;Techniques are informative&quot; section. But my first choice would be &quot;Sufficient Techniques&quot;. <span style="color:#808080;">{dboudreau, Aug4th.}</span></li>
<li style="margin-top: 1em;">I feel that for those unitiated into the special language of standards it will be a somewhat confusing and meaningless sentence. If it is intended for ordinary people it would be nice to have an ordinary language version so that they can truly understand the balance between normative and informative. Perhaps there could be a link to a plain text easy to understand version?<span style="color:#808080;">{Suzette 5th August}</span></li>
<li style="margin-top: 1em;">I think the Notes break the flow but I do think a point made in both sections would carry the message forward. As such, a suggestion follows:<span style="color:#808080;">{Vicki, August 9}</span>
<p><strong>Reminder: </strong></p>
<ul>
<li>Sufficient techniques are provided as guidance. A frequent misunderstanding is that they should be used for meeting conformance. The only thing that should be required is meeting the WCAG 2.0 success criteria and not the techniques which are informative. There can be <a href="http://www.w3.org/WAI/WCAG20/wcag2faq.html#techsnot">negative consequences of allowing only W3C's published techniques to be used for conformance to WCAG 2.0</a>.</li>
<li>Techniques for WCAG 2.0 use the words &quot;must&quot; and &quot;should&quot; only to clarify guidance within the techniques, not to convey requirements for WCAG</li>
</ul>
</li>
<li style="margin-top: 1em;">From <a href="http://lists.w3.org/Archives/Public/w3c-wai-eo/2013JulSep/0021.html"> EOWG e-mail</a>:
<ul>
<li> It is ok where it is but should be worded as &quot;It is important to note that ...&quot;, instead of just &quot;Note:&quot;. Notes like those are generally considered supplementary / advisory info and can be missed easily. Alternatively it should be moved up in that section nearer to the beginning and not be called a &quot;Note&quot;. <span style="color:#808080;">{Sailesh}</span> </li>
<li> I agree with Sailesh in that it could stay where it is but needs to stand out more. If it is moved to the sufficient techniques section, it should still be made to stand out. I think the idea that W3C cautions against something is a pretty strong statement and it is important that it not be missed. Perhaps that sentence or the words &quot;cautions against&quot; should be marked up in strong. <span style="color:#808080;">{Catherine}</span> </li>
<li> I agree with Andrew that the &quot;Techniques are Informative&quot; section refers to &quot;Sufficient Techniques.&quot; <br/>
Advisory Techniques and Failures are by nature not required. I assume that using a separate section is to emphasize the notes, but on first reading I found the section heading a little confusing, especially as it's followed by so many other headings, all with the word &quot;Techniques.&quot; It rather upsets the flow of ideas to have a disclaimer as the first section. <br />
I think it would be more coherent to make it a subsection of &quot;Sufficient Techniques.&quot; <span style="color:#808080;">{Alan}</span> </li>
<li> &quot;Alternatively it should be moved up in that section nearer to the beginning and not be called a &quot;Note&quot;.&quot; I agree. <span style="color:#808080;">{Kathleen}</span> </li>
</ul>
</li>
</ul>

Summary: The text for the SC's intent is not worded right; the benefits are incomplete /mis-represented

Refer to: The intent of this Success Criterion is to help users avoid making mistakes when their input is required. To help avoid mistakes it is good user interface design to provide simple instructions and cues for entering information.
Some users with disabilities may be more likely to make mistakes than users without disabilities or recovery from mistakes may be more difficult, making mistake avoidance an important strategy for users with disabilities. People with disabilities rely on well documented forms and procedures to interact with a page. Blind users need to know exactly what information should be entered into form fields and what the available choices are.
And one of the benefits is:
•Providing examples of expected data formats help users with cognitive, language and learning disabilities to enter information correctly.

Comment:
As the Web page author if I placed 2 edit boxes for last and first name respectively (without any labels or instructions), will a sighted non-disabled user know what these controls are for and not make mistakes?
Simply put, the primary objective of the SC is to require labels or instructions that clearly convey what input data is expected in a form control.
In other words the purpose of the control should be clearly indicated.
By the very definition of the term label in WCAG2,
- the label is supposed to identify the component, the form control in this case.
- the label is supposed to be available to all users.
The intent skirts this altogether.
Then there are passwords that are valid without number or special character or upper case letter ... for different websites.
So anyone can make mistakes if the expected data format is not specified when it is out of the ordinary - nothing to do with "users with cognitive, language and learning disabilities".
Likewise, if required fields are not indicated, any user's form submission may fail.
Labels for form controls are not placed primarily to prevent users from making mistakes but to identify the control in the first place.
There are other SC that deal with error identification and recovery.
A significant benefit of explicit label association that helps some users click on a label to move focus into the field or check a checkbox / radio button is not mentioned at all.

Proposed wording:
The intent of this success criterion is to have content authors place instructions or labels that identify the controls in a form so that users know what input data is expected.
Instructions or labels may also specify data formats for fields especially if they are out of the customary formats or if there are specific rules for correct input.
Content authors may also choose to make such instructions available to users only when the individual control has focus especially when instructions are long and verbose.
It is customary to place labels to the left of (or above) text boxes. Labels for radio buttons / checkboxes are often to the right of the control.
There are specific benefits of using labels:
i. When label elements are associated with input elements:
- the label is spoken by screen readers when the field receives focus.
- users with impaired motor control are helped by a larger clickable area for the control, since clicking on the label or the control will activate the control.
ii. Field labels located in close proximity to the associated field assist users of screen magnifiers because the field and label are more likely to be visible within the magnified area of the page.
iii. Specifying data formats for fields where appropriate and identifying required fields increases the likelihood of successful first-time form submission.

Resize Text: Understanding SC 1.4.4.

Problem:
Refer to the 5th para, 2nd sentence, “For example, in Web mail applications
the subject column may not wide ...” at
http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html
Proposed Change:
Add “be” to make the sentence grammatically correct.

-Devarshi

Should this type of information not be a feature of the WAI site, so that the link location can be controlled and reviewed on a regular basis?


Proposed Change:
The information (missing link) can now be found at:
http://www.bbc.co.uk/accessibility/guides/change_colours/

Name: James Nurthen
Email: james.nurthen@oracle.com
Affiliation: Oracle
Document: UW
Item Number: Understanding Success Criterion 1.4.4
Part of Item: Intent
Comment Type: technical
Summary of Issue: Firefox supports zoom
Comment (Including rationale for any proposed change):
The 3rd paragraph states
"The author cannot rely on the user agent to satisfy this Success Criterion for HTML content if users do not have access to a user agent with zoom support. For example, if they work in an environment that requires them to use IE 6 or Firefox."

Firefox has supported zoom for a long time. I suggest dropping the mention of Firefox

Proposed Change:
change paragraph 3 to

The author cannot rely on the user agent to satisfy this Success Criterion for HTML content if users do not have access to a user agent with zoom support. For example, if they work in an environment that requires them to use IE 6.