ATAG2 several unaddressed comments discovered

Hi all,

In finishing the proposed responses, I found several mostly-minor issues outstanding. I have included them here (marked normative or informative) with proposals:


Definition of "At Least as Prominent":
--------------------------------------
(NORMATIVE)

COMMENT:
MS53: B.2.5.4 What happens when there is a large variety of template of all different sorts? The language suggests that the "accessible" option must take precedence regardless of other logical grouping. Please change the SC to account for other logical grouping of templates.

PROPOSAL:
[1a] Attempt to clarify this by putting in an OR.
At least as prominent: 
For purposes of conformance to ATAG 2.0, an item A is considered to be "at least as prominent" as an item B if at least one of the following is true:
(a) item A occurs higher in the default reading order than item B; or
(b) both items occur in the same item container (e.g. menu of items, list of items, list of tabs, dialog of text entry fields) and if item B is always highlighted, then so is item A; or



Indicators of template accessibility (B.2.4.2 Template Selection Mechanism):
----------------------------------------------------------------------------
(INFORMATIVE)

COMMENTS:
MS52: B.2.5.4 Please provide examples of how one goes about indicating the accessibility status of a template...
GL41. MINOR: Indicators during template selection. Re "B.2.5.4 Template Selection Mechanism", would you really recommend listing entries like "slide show template - wcagA"?...

PROPOSALS: 
[2a] Revision of Intent of Success Criterion B.2.4.2:
The intent of this success criterion is to ensure that authors can easily determine the accessibility status of templates prior to selecting them and to increase the likelihood that authors will notice the accessible template options.
Note: The term "accessibility status" is used, rather than "WCAG 2.0 conformance", for the sake of flexibility, meaning that the status values are not required to include the term "WCAG" explicitly.

[2b] Revision of Examples of Success Criterion B.2.4.2:
- Accessibility status as metadata: An HTML editor includes a template selection mechanism that consists of a list of selectable items. The template list has several sortable fields that are populated from the templates' metadata: the template name, date, popularity and accessibility status. The accessibility status values are: "Level A", "Level AA", "Level AAA", "None" and "Not Available". By default, the list of templates is sorted alphabetically, but the author has the option to sort by accessibility status instead. The accessibility status values of the developer-provided templates are based on the degree to which WCAG 2.0 success criteria are met when the template is used (see definition of "accessible template"). This may have been assessed manually or semi-automatically with an accessibility checker.
- Accessibility status included in template names/descriptions: In a wiki system, creating a new page brings up a list of available templates. Each template is only displayed as a name and a short description. When the developer has ensured the accessibility of a template this is indicated by the template name (e.g. "slide show template (accessible)") and/or information in the description ("This template meets WCAG 2.0 Level A as provided and should result in an accessible page if accessible authoring practices are followed.").



Rationale for Guideline A.4.1 (Help authors avoid and correct mistakes)
-----------------------------------------------------------------------
(INFORMATIVE)

COMMENT:
GL36. MINOR: AT also introduces errors. In "Implementing Guideline A.4.1: [For the authoring tool user interface] Help authors avoid and correct mistakes", the rationale could include not only people who have difficulty with fine motor control, but also those who rely on assistive technologies such as speech recognition, which introduce errors through misrecognition.

PROPOSAL: 
[3a] Reword rationale:
Some authors with disabilities may be more susceptible to input errors due to factors such as difficulty making fine movements and speech recognition system errors.



More examples for B.2.2.1 Accessible Option Prominence
-------------------------------------------------------
(INFORMATIVE)

COMMENTS:
GL42. MINOR: Another example of Accessible Options Prominent. In "Implementing Success Criterion B.3.1.1 Accessible Options Prominent (WCAG Level A)" you might include as another example that if a WYSIWIG editor includes a toolbar button to bold text, it should be implemented using <strong> rather than <span> (although it is welcome to use a specific style or class on the strong element if it wants to ensure that the user agent renders it as bold rather than using an alternative rendering).
OC29: -B.3.1.1 - We suggest that things like lists and tables should be added to the examples since these are challenging situations.

PROPOSALS: 
[4a] Added intent text:
The intent of this success criterion is to help ensure that accessible authoring practices are part of the default workflow of authoring tools.
This requirement applies when the authoring outcome is predictable by the authoring tool. For example, a generic "insert table" command would not applicable, despite the fact that an author might misuse it for layout, because the author might be seeking the outcome of adding tabular information. In contrast, a page layout editor is covered by the requirement because the purpose of the feature is to edit the page layout.

[4b] Rewording examples:
- Structural Markup: A WYSIWYG HTML editor does not include any authoring action options for authors that will necessarily result in web content that will not conform to WCAG 2.0 Level A. For example:
 + a toolbar button that allows text to be marked bold does so by adding a <strong> element rather than a <span> with a bold style. 
 + a the toolbar button for placing text into a bulleted list does so with list markup (<ul> and <li> elements) rather than a <span>-based implementation.
 + a page layout view makes use of CSS positionning rather than table markup. 
- De-emphasizing problematic options: A WYSIWYG editing-view emphasizes more accessible choices with a higher position in the menus and a position in user interface shortcuts such as toolbars. Choices that always lead to less accessible web content are de-emphasized with lower menu position.




-- 
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://idrc.ocad.ca/
Faculty of Design | OCAD University

Received on Friday, 1 April 2011 17:10:49 UTC