- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Mon, 11 Jan 2010 12:49:30 -0500
- To: w3c-wai-au@w3.org
Hi all,
I had 4 action items from the last meeting....
----------------------------------------------------
ACTION: JR to Add "Remember" sections in context as proposed text - also
reword the "manual" check/repair clarifications to more positively
portray automated and semi-autoameted without removing the possibility
of the manual option
- I'm having second thoughts about adding new language ("Remember")
outside the normative success criteria, since this is even further from
the SC's that seem to be confusing people. Instead let's revise the SC
notes.
- How about this for less negative text for the note:
Note: While automated checking or more advanced implementations of
semi-automated checking are possible for many types of web content
accessibility problems, manual checking is the minimum requirement to
meet success criteria B.2.2.1, B.2.2.4 and B.2.2.10. In manual checking,
the authoring tool provides authors with instructions for detecting
problems, which authors must carry out by themselves without further
automated assistance. For more information on checking, see Implementing
ATAG 2.0 - Appendix B: Levels of Checking Automation.
----------------------------------------------------
ACTION: JR to Take A.3.6 back to drawing board - add points about when
to pass OS and when perhaps not
- How about?
+A.3.6.1 Save Settings: Authoring tool *display settings* and *control
settings* are saved between sessions. (Level AA)
+ Define "control settings" as:
Settings that relate to how the author controls the authoring tool, for
example using the keyboard or mouse.
+ A.3.6.2 Multiple Sets: The author(s) can save and reload multiple sets
of any authoring tool *display settings* and *control settings*.(Level AAA)
+ A.3.6.X Respect Platform Settings: The authoring tool respects
platform *display settings* and *control settings*. (Level AA)
Note: As per Guideline A.2.3, the author's display settings must still
be independent of the web content being edited.
A.3.6.3 Options Assistance: The authoring tool includes a mechanism to
help the author(s) configure ANY options related to Part A. (Level AAA)
- BTW: I wouldn't be heartbroken to see A.3.6 disappear. I don't think
it is especially authoring tool-specific.
----------------------------------------------------
ACTION: JR to reword proposal with applicability instead of
responsibility. [applies to Part B: Responsibility After Authoring Sessions]
New suggestion:
Applicability after the *End of an Authoring Sessions*:
For *author-generated content*, the requirements of *Part B* apply only
during *authoring sessions*. For example, if the *author* includes a
third-party feed in their *web content*, the *authoring tool* is not
required to provide *checking* for *web content accessibility problems*
in that feed after the *end of the authoring session*. In contrast, for
*automatically-generated content*, Part B continues to apply after the
*end of an authoring session*. For example, if the site-wide templates
of a content management system are updated, these would be required to
meet the accessibility requirements for *automatically generated content*.
----------------------------------------------------
[NEW] ACTION: JR to Write some intent text for B.1.1.1 to explain that
instead of accessibility supported uses we took the decision support
approach in B.2.1
- This is always such a can of worms...
- I think that because we mention "conformance to WCAG 2.0" all over the
place, this is a larger issues that should address head-on in
"Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0 "
- Here is my attempt at renewing how we talk about WCAG:
(1) In general, we might consider saying something like "meets the WCAG
2.0 success criteria" instead of "conforms to WCAG 2.0" to lessen the
confusion.
(2) And I think a rewording of the "Relationship to the Web Content
Accessibility Guidelines (WCAG) 2.0" is in order:
In order to make recommendations regarding (1) the accessibility of
web-based authoring tool user interfaces (in Part A) and (2) how authors
should be enabled, supported, and guided towards producing accessible
web content (Part B), ATAG 2.0 relies on the concept of *accessible web
content*. Since, as of publishing, WCAG 2.0 is the most recent W3C
Recommendation regarding web content accessibility, ATAG 2.0 references
WCAG 2.0 in its definition of accessible web content.
*Note on Specific Technologies:*
It is important to note that the normative success criteria in WCAG 2.0
are not technology-specific. Specific informative (non-normative)
guidance for satisfying the success criteria for particular web content
technologies are provided for WCAG 2.0 in separate documents (e.g., How
to Meet WCAG 2.0).
When ATAG 2.0 requires "information on how the web content technology
might be used to create accessible web content" for *Included
Technologies* in the *Required Components of an ATAG 2.0 Conformance
Claim*, this is intended to document the authoring tool's actual
implementation, not imply that the web content techniques that an
authoring tool supports are normative.
*Note on "Accessibility-Supported Ways of Using Technologies":*
WCAG 2.0 includes a conformance requirement that "only
accessibility-supported ways of using technologies are relied upon to
satisfy the success criteria. Any information or functionality that is
provided in a way that is not accessibility supported is also available
in a way that is accessibility supported." In broad terms, a technology
is considered accessibility supported when (1) the way that the Web
content technology is used is supported by users' assistive technology
and (2) the Web content technology has accessibility-supported user
agents that are available to users. WCAG 2.0 notes that "accessibility
support of Web technologies varies by environment...[and] by language
(and dialect)". For more detailed information, see WCAG 2.0.
Extending this concept to authoring tools is problematic because (1)
authoring tools are marketed and used across organizational, political
and linguistic borders and (2) the context of use of an authoring tool
is usually set by each person who installs the software and acts as an
author. Therefore:
*When any ATAG 2.0 success criterion requires web content to meet the
requirements of WCAG 2.0, specifying "accessibility-supported ways of
using technologies" is not required.*
Of course, once an authoring tool has been installed and put into use,
it would be appropriate for the web content it produces to be assessed
for WCAG 2.0 conformance, including whether "only
accessibility-supported ways of using technologies are relied upon to
satisfy the success criteria".
Talk to everyone at 3pm.
Cheers,
Jan
--
Jan Richards, M.Sc.
User Interface Design Lead
Adaptive Technology Resource Centre (ATRC)
Faculty of Information
University of Toronto
Email: jan.richards@utoronto.ca
Web: http://jan.atrc.utoronto.ca
Phone: 416-946-7060
Fax: 416-971-2896
Received on Monday, 11 January 2010 17:50:03 UTC