Items in the AUWG survey

Hi all,

Yesterday I sent the URL of the survey. Some of the items go a bit 
beyond editorial, so here they are in an email with explanations where 
necessary:

(1) Term to use to replace freehand drawing in "A.3.1.1 Keyboard Access
(Minimum): All functionality of the authoring tool is operable through a
keyboard interface, except for freehand drawing@@":
- freehand drawing (NO CHANGE)
- freehand input
- continuous freehand input
- continuous pointing device input

EXPLANATION: We didn't come to agreement on this on Monday. Please feel
free to send in other ideas.


(2) New Text in Intent of Success Criterion A.2.2.2:
"This success criterion pertains to the rendered properties of text on
the screen, even if the properties differ from the web content being
edited. For example, when an author that chosen their own display
settings (as per Success Criterion A.2.3.1)."

EXPLANATION: This just clarifies what should be communicated
programmatically when the author has set display settings that differ
from the default WYSIWYG.


(3) New Text in Intent of Success Criterion A.3.1.2:
"The first requirement (a) applies only to the authoring tool user
interface, which is the part of the authoring tool that developers have
the most control over. In this case, there simply should not be keyboard
traps. If the author can move focus to a component using standard
keyboard navigation commands (e.g., using the tab key), then they must
be able to move focus out of the component in the same way. The second
requirement (b) applies to renderings of web content. Because the web
content may contain keyboard handlers, the authoring tool may not be
able to prevent keyboard traps entirely. Therefore, the requirement is
only that the authoring tool be able to restore the keyboard focus to
some know location. This known location could be outside of the rendered
area (e.g., the menus) or it might be the next rendered element."


(4) New Text in Intent of Success Criterion A.3.4.1:
"Of course, the editing mechanisms would be contingent on the web
content containing the appropriate structure. For example, editing by
structure would not be very effective in an HTML document composed of
plain text in a pre element."


(5) New Text for Intent of Success Criterion A.3.4.2
"The intent of this success criterion is to help authors using a
keyboard interface to navigate more efficiently within structured web
content. Because web content technologies differ in the types of
structure that they include, developers have flexibility to decide what
types of navigation mechanisms to include. The following list contains
some possibilities:
(a)tree navigation: the ability to move focus to the elements up, down
and across tree structures.
(b)navigation by headers: the ability to move focus between elements
identified as headers in the markup (e.g., h1, h2, etc in HTML4).
(c)navigation by element: the ability to move focus between element of
the same type or sharing particular attributes.
(d)navigation by role: the ability to move focus between elements
identified by their roles
(e)navigation by accessibility relationships: the ability to move focus
between elements bound by accessibility relationships (for attribute of
label in HTML4, aria-describedby, etc.).

Of course, the navigation mechanisms would be contingent on the web
content containing the appropriate structure. For example, navigation by
headers would not be very effective in an HTML document that did not
contain headers."


(6) Changed text in B.1.2.1 and B.1.2.3:
"preserved as accessibility information in the output,"


(7) Reworded B.2.1.3 "Other Technologies: If the authoring tool enables
web content to be inserted that the authoring tool cannot be used to
edit, then the author(s) can associate accessibility information with
that web content"


(8) Reworded note for B.2.2.1, B.2.2.5, and B.2.2.10
"Note: Automated and semi-automated checking is possible for many types
of web content accessibility problems. However, manual checking is the
minimum requirement to meet this success criterion. In manual checking,
the authoring tool provides authors with instructions for detecting
problems, which authors must carry out by themselves. For more
information on checking, see Implementing ATAG 2.0 - Appendix B: Levels
of Checking Automation."


(9) Level A for B.2.2.4 Help Authors Locate

EXPLANATION: Suggested by a commenter.


(10) Added text to B.2.2.7:
"later repair"


(11) New text for Related Resources for Success Criterion B.2.2.8:
"- The IMS AccessForAll Meta-data standard is one way to store the
accessibility attributes of web content in order to match them with the
preferences of users. This system is also the basis for ISO 24571
(Individualized adaptability and accessibility in e-learning, education
and training).
- The Evaluation and Report Language (EARL) is a machine-readable format
for expressing test results.
- Google Accessible Search is an example of accessible resource discovery."


(12) Added text to B.2.2.9:
with external repair tools.


(13) Note for B.2.3.1,B.2.3.2,B.2.3.3
"Note: Automated and semi-automated repair is possible for many types of
web content accessibility problems. However, manual repair is the
minimum requirement to meet this success criterion. In manual repair,
the authoring tool provides author(s) with instructions for repairing
problems, which authors must carry out by themselves. For more
information on repair, see Implementing ATAG 2.0 - Appendix C: Levels of
Repair Automation."


(14) Rewording in B.2.5.1, B.2.5.3, B.2.5.9:
"Templates Accessible (WCAG Level A): If the authoring tool
automatically selects templates or pre-authored content, then the
selections conform to WCAG 2.0 Level A when used. (Level A)
Note: Templates may be complicated to check for accessibility due to
their inherent incompleteness. The accessibility status of templates is
instead measured by the accessibility of web content (in the final web
content technology) created when the templates are used properly."


(15) Rewording Intent of Success Criterion B.3.2.4:
"The intent of this success criterion is to help ensure that authors are
as likely to notice and use functions for addressing accessibility
problems as functions for addressing other web content issues (e.g.,
invalid markup, syntax errors, spelling and grammar errors)."


(16) Removing unused term "abbreviation" from glossary

EXPLANATION: We don't use it anymore.


(17) Removing unnecessary term "option" from glossary

EXPLANATION: I think we use the term in its usual way.


(18) Proposal to remove Appendix B: How to refer to ATAG 2.0 from other
documents

EXPLANATION: It's not something WCAG 2.0 has anymore


Cheers,
Jan


-- 
(Mr) Jan Richards, M.Sc.
jan.richards@utoronto.ca | 416-946-7060

Adaptive Technology Resource Centre (ATRC)
Faculty of Information | University of Toronto

Received on Thursday, 11 February 2010 18:54:27 UTC