Disposition of comments for the Accessibility Guidelines Working Group

I understand that it's called "focus order", but this SC refers to “navigation”, as does the Guideline. I get how tabbing between links / fields might seem like "navigation", but that seems very HTML/Flash-specific and it's not even fair to those formats (frankly) either, since that's hardly the only (or primary) means of "navigation" in HTML, at least.

SC 2.4.3 is the _only_ Level A criterion that mentions "navigation", and yet judging by the Techniques (HTML and PDF) it's understood to be only applicable to content that includes focusable (read "input") elements. I don't understand this at all, and I did not find the "Understanding" text enlightening. Indeed, that text is suggestive in appearing to support (in part) my understanding of SC 2.4.3 that the SC's intent is more general than the traditional elements than "receive focus".

Since the SC appears to pertain to navigation, and if "focus" reasonably also includes structure elements, I would expect PDF9 to apply to this SC.

Proposed Change:
Add PDF9 to this SC. Also, I suggest considering that "navigation" goes beyond input elements - that's certainly the case in PDF, for example, and I would suspect, in other formats as well.

I am trying to reconcile the fact of F43 with a common (but by not means general) impression that SC 1.3.1 does not require logical hierarchy in headings.

Success Criterion 1.3.1 requires that if headings are in the content that relationships are conveyed programmatically.

Now, illogical heading hierarchy does not, as has often been claimed, leave “equivalent information” available to everyone.

This claim rests on the incorrect assumption that every user will find a given structural anomaly disconcerting (or not) to a similar degree. This is obviously not the case as WAI is, I know, aware. Page-position alone can provide information that effectively removes an "important" but non-structural "structure" element from the sighted user's perception of the content's organization.

Instead, the reality is that users who depend on heading structure for navigation receive a substantially less effective navigation facility when the structure model is abused for presentational purposes.

The whole point of 1.3.1 is to eliminate practices that reliably botch the conveyance of “information, structure and relationships” to the user by way of normatively requiring “programmatic determinability”. Elegant! I applaud F43. It embodies 1.3.1 precisely because it fails the misuse of structure elements.

Now, there is – of course – a big variable in impact based on the nature of the content. This issue matters a lot less on short (typical web-page) content with few headings. On longer or highly structured content it is entirely fair to state that misuse of section headings for emphasis or styling kills the utility of headings as a reliable means of navigation for those who depend on structure to operate their AT.

When it doubt the reading of the normative text should err towards the side of accessibility rather than its opposite.

I’m not suggesting that headings must be used – that’s absurd. I am suggesting that IF headings are used to structure content (ie, to serve the “section heading” role), then they must make sense to pass 1.3.1.

In any event, we are attempting to implement F43. It seems clear that F43 suggests that we fail content with illogical heading levels unless some other “programmatically determinable” means is provided to discern the “real” headings from the other “uses” of <H#> tags. Whatever that could be.

I have discussed this precise question with at least two-dozen experts in ICT accessibility over the past four months and have received almost the same number of opinions. ☹

In the use-cases of MY great interest – longer and structured documents – the significant majority of experts I consulted preferred to consider valid heading structure as normatively required, even if they were not sure whether or not WCAG 2.0 required it.

Proposed Change:
I think the Committee should rectify the (apparent) delta between F43 and the otherwise-stated view that “WCAG does not require strict hierarchy in headings”, including as 'represented' in H42, example 2.

Further, I think the Committee should consider that very significant use-cases exist in which 1.3.1 becomes substantially meaningless if it is NOT understood to require logically structured headings.

I believe it's a lot easier to write Techniques for 1.3.1 if one takes this view, and far easier to implement as well. More to the point, the quality and accessibility of content will improve at every level.

Please add an item to "Failures for SC 2.4.3 - Focus Order". Numerous websites cannot be navigated with a keyboard because the designer behind it hides the visual focus with CSS (outline:none). Also, many reset stylesheets contain this CSS rule, and therefore it's usage is widespread.

Proposed Change:
Add hiding keyboard-focus with CSS (outline:none) to "Failures for SC 2.4.3 - Focus Order".

I recently tested a site that contains a lot of images. None of the images has an alt attribute but they all have a title attribute. I tested with two versions of Jaws and the latest version of NVDA and the title attribute was read in all three cases. Does the title attribute have enough support to be considered a sufficient technique?

I've found a number of pages that set the main page container to overflow: hidden thus preventing horizontal scrollbars from appearing when resizing the page. Skittles.com is an example.

Add a new failure stating any technique that prevents scrollbars from appearing when the page is resized that also causes the text/content from being cut off would fail this success criteria.

Proposed Change:
Known failure: setting the overflow style to hidden on containing elements preventing scrollbars to appears when the page is zoomed up to 200% in the user agent.

H69 by itself will not be able to satisfy the accessibility needs of
sighted keyboard only users and hence is not sufficient for SC 2.4.1
(bypass blocks).
Proposed Change:
Remove it from the list of sufficient techniques and merge it with H42.

Comment (Including rationale for any proposed change):
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 Change:
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.

Comment (Including rationale for any proposed change):
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 Change:
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.

When auditing sites for compliance I come across many pages where the text does not resize (when this option is selected) but if zoomed to 200% it does. The critera talk about resizing the text, but also about zooming the page. Does it need to do both, one of, or one in preference of the other.

Proposed Change:
Clarify what fails i.e if the text cannot be resized then it is a fail - or if the text resizes when zoomed it passes (dependant on presentational issues)

One more question about that. "Focus order" is a level A criteria. Hiding the visual outline is a failure of "Focus visible", which is a level AA criteria.
To be able to see the tab or "focus order level A" (for example sighted keyboard users), one much comply with "focus visible level AA".
If focus order cannot be achieved without focus visible, why are the not in the same level?

I really appreciate all your help.

I'd like to ask you an additional question.

Should the link text be the same to meet SC 3.2.4 if they are the
links for the same resource?
Please see the CASE 1-2 and 3-2 below. Do they meet SC 3.2.4?

> CASE 1:
> <p>
> <a href="xxx.html><img src="xxx.png" alt="WCAG 2.0"></a>
> <a href="xxx.html>WCAG 2.0</a>
> </p>

CASE 1-2:
<p>
<a href="xxx.html><img src="xxx.png" alt="WCAG 2.0"></a>
<a href="xxx.html>About WCAG 2.0</a>
</p>

> CASE 3:
> <p>
> <a href="xxx.html><img src="xxx01.png" alt="WCAG 2.0"></a>
> <a href="xxx.html><img src="xxx02.png" alt="WCAG 2.0"></a>
> </p>

CASE 3-2:
<p>
<a href="xxx.html><img src="xxx01.png" alt="WCAG 2.0"></a>
<a href="xxx.html><img src="xxx02.png" alt="About WCAG 2.0"></a>
</p>