Changes to the current ATAG2 draft before Last Call publication

APPROVED:
=========
(1) Change to A.3.2.3 (http://www.w3.org/2010/06/07-au-minutes.html#item03)


EDITORIAL:
==========
(1) "Implementing Success Criterion" is accidentally showing for A.3.1.6 
Present Keyboard Commands

(2) Alistair's:
Appendix F (Comparison 1.0 to 2.0): The page it goes to is marked as 
Appendix B, rather than F.

(3) B.2.3.1, B.2.3.2, B.2.3.3 have different wording of "(required in 
X)" let's standardize to (as required by Success Criterion B.2.2.X)"


MINOR:
======
(1) Adding "Any":
A.3.6.1 Save Settings: Any authoring tool display settings and control 
settings are saved between authoring sessions.
(http://lists.w3.org/Archives/Public/w3c-wai-au/2010AprJun/0065.html)

----

(2) Adding "Any":
"A.3.1.6 Present Keyboard Commands: Authoring tool user interface
controls can be presented with any associated keyboard commands. (Level
AAA)"

----

(3) PROPOSAL: Split "content (web content)" and "Web content 
properties". Without any other substantive change. Both are already 
defined terms.

content (web content)
Information and sensory experience to be communicated to the end user by 
means of a user agent, including code or markup that defines the
content's structure, presentation, and interactions. In ATAG 2.0, the
term is primarily used to refer to the output that is produced by the
authoring tool. Content produced by authoring tools may include web
applications, including those that act as web-based authoring tools.
Accessible web content is web content that conforms to a particular
level of WCAG 2.0 (see Relationship to WCAG 2.0 section). Structured web 
content is content that includes machine-readable internal structure 
(e.g., markup elements), as opposed to unstructured content, such as 
raster image formats or plain human language text.

content (web content) properties
The individual pieces of information that make up web content (e.g., the 
attributes and contents of elements, stylesheet information, etc.).
While many web content properties have discrete values (e.g., a single
value for size, color, font, etc.), some types of web content
(especially graphics) may includes properties that can be said to encode 
continuous input because they incorporate frequent data samples (e.g., 
the location, speed, pressure, angle, etc. of a pointing device) . For 
example, a freehand line graphic object might have a "continuous" path 
property that encodes thousands of individual x-y location values, but 
"discrete" properties for setting the color and thickness of the line. A 
"watercolor stroke" graphic object might have multiple "continuous" 
properties (e.g., path, speed, pressure) in order to graphically mimic 
the diffusion effects that occur when a real paint brush is moved in a 
similar manner.


MORE SUBSTANTIVE:
=================

(1) Removing "A.3.1.3 Keyboard shortcuts are provided."
- Since for desktop systems it will already be covered by "A.1.2.1 
Non-Web-Based Accessible: Non-web-based authoring tool user interfaces 
follow accessibility standards and/or platform conventions that support 
accessibility. (Level A)"

(2) Rewording: B.2.2.1 Check Accessibility (WCAG Level A): If the 
authoring tool provides authors with the ability to add or modify web 
content so that any WCAG 2.0 Level A Success Criteria are violated, then 
accessibility checking for those success criteria is provided. (Level A)
NOTE IS UNCHANGED
- I think this wording preserves our intent without the perhaps overly 
restrictive "At least one individual check..." language.



Cheers,
Jan


On 08/06/2010 4:39 PM, Jan Richards wrote:
> Hi Alistair,
>
> Thanks a lot for these comments. Here are my thoughts (including
> proposed changes that we can decide upon on Monday's call):
>
>
> On 08/06/2010 4:52 AM, Alastair Campbell wrote:
>> Hi everyone,
>>
>> I'm new here, and it's been a few years since I read through ATAG 2.0,
>> so it's quite fresh to me.
>>
>> At a high level, it's a big improvement in terms of readability&
>> understandability compared to what I remember.
>
> JR: Great!
>
>> It still has the 'huge checkpoints' (from a testing point of view),
>> where it refers across to the entirety of WCAG 2.0, but I can't see
>> any way around that!
>
> JR: Unfortunately agreed.
>
>> I have a few questions on higher level points, apologies if I've
>> mis-read or understood something, I'm happy to be pointed in the right
>> direction. On the other hand, if these seem like real issues, I'll
>> start thinking of updates to the documents.
>>
>>
>> A.3.6: Manage preference settings.
>>
>> This guideline seems to be an implicit requirement that Authoring
>> tools have preference settings. From a web-CMS point of view you can
>> build in useful preferences, but at a single-A level I would have
>> thought respecting users' system/browser settings would be sufficient?
>>
>> That may be the case (there is no single-A guideline), but a straight
>> reading implies that you must have preferences.
>
> JR: As you say, there is no Level-A requirement, but I agree. In
> "A.3.6.3" we say "Any...settings". We should do the same in A.3.6.1, as in:
>
> PROPOSAL:
> A.3.6.1 Save Settings: Any authoring tool display settings and control
> settings are saved between authoring sessions.
>
>
>> A.3.1.3 Keyboard shortcuts are provided.
>>
>> Having campaigned against (or at least for careful use of) accesskeys,
>> this feels like a step back. With WCAG 1.0 and accesskeys, developers
>> rarely understood the implications and unintentionally abused accesskeys.
>>
>> However, the context of authoring tools is different from a standard
>> website, and I can certainly see the usefulness of keyboard short-cuts
>> for editing where you want to move quickly between a text area and a
>> menu.
>>
>> Taking inspiration from WCAG 2, could it be termed as something like
>> "A mechanism is available to navigate to known points of an editing
>> environment via the keyboard."
>>
>> If not, perhaps separating a browser based context from native
>> applications would help?
>
> JR: I wonder if this could be safely dropped. For platforms that had
> workable support for keyboard shortcuts it would be picked up by
> "A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user
> interfaces follow accessibility standards and/or platform conventions
> that support accessibility. (Level A)"
>
> Thoughts?
>
> ALSO SHOULD "A.3.1.6 Present Keyboard Commands: Authoring tool user
> interface controls can be presented with their associated keyboard
> commands. (Level AAA)" USE "ANY" AS IN:
> "A.3.1.6 Present Keyboard Commands: Authoring tool user interface
> controls can be presented with ANY associated keyboard commands. (Level
> AAA)"
>
>
>> B.2.2 Assist authors in checking for accessibility problems.
>>
>> My first impression of this was that it would turn regular authors
>> into accessibility auditing specialists! I don't think that's actually
>> the case, but I can see CMS vendors getting worse at 'crying wolf'.
>>
>> Too often I've seen accessibility checks (either built in or separate)
>> get ignored because they are so repetitive. The same issues come up
>> again and again, sometimes because they are manual checks, sometimes
>> false positives, but the effect is that they are ignored.
>>
>> As a general rule, I prefer prevention to cure. For example, providing
>> pre-set styles rather than font-color pickers.
>>
>> Obviously ATAG needs to cater for situations when authors do have
>> control over everything, so I'll see if I can think of a way to
>> indicate that checks should be included for items that the author has
>> control over (i.e. the things that *can* go wrong).
>
> JR: That's what we tried to do with this phrase "...that the authoring
> tool has the functionality to modify web content to meet (e.g., an HTML
> authoring tool that inserts images should check for alternative text; a
> video authoring tool with the ability to edit text tracks should check
> for captions)..."
>
> But, the wording could be more clear....
> PROPOSAL:
> B.2.2.1 Check Accessibility (WCAG Level A): If the authoring tool
> provides authors with the ability to add or modify web content so that
> any WCAG 2.0 Level A Success Criteria are violated, then accessibility
> checking for those success criteria is provided. (Level A) [Implementing
> B.2.2.1]
> Note: Automated and semi-automated checking is possible (and encouraged)
> 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.
>
>
>> When creating guidelines that try to cover such a wide range of tools
>> it's difficult to encourage a minimalist approach! For example, one of
>> the easiest ways to meet WCAG 2.0's 1.3 (Adaptable) is not to provide
>> style controls.. When working from pre-set styles authors don't have
>> to worry about contrast, so that would never come up as a check.
>> However, feature driven development tries to include everything. :-/
>  >
>> Two minor points:
>>
>> The term "encode continuous input" in the glossary is part of "content
>> (web content)" and is referred to from A.3.1.1, but I struggled to
>> find it without doing a text-search. Would it be possible to separate
>> out?
>> http://www.w3.org/WAI/AU/2010/ED-ATAG20-20100420/#def-Web-Content
>
> JR: OK...
> PROPOSAL: Split "content (web content)" and "Web content properties"
>
> content (web content)
> Information and sensory experience to be communicated to the end user by
> means of a user agent, including code or markup that defines the
> content's structure, presentation, and interactions. In ATAG 2.0, the
> term is primarily used to refer to the output that is produced by the
> authoring tool. Content produced by authoring tools may include web
> applications, including those that act as web-based authoring tools.
> Accessible web content is web content that conforms to a particular
> level of WCAG 2.0 (see Relationship to WCAG 2.0 section). Structured web
> content is content that includes machine-readable internal structure
> (e.g., markup elements), as opposed to unstructured content, such as
> raster image formats or plain human language text.
>
> Web content properties
> The individual pieces of information that make up web content (e.g., the
> attributes and contents of elements, stylesheet information, etc.).
> While many web content properties have discrete values (e.g., a single
> value for size, color, font, etc.), some types of web content
> (especially graphics) may includes properties that can be said to encode
> continuous input because they incorporate frequent data samples (e.g.,
> the location, speed, pressure, angle, etc. of a pointing device) . For
> example, a freehand line graphic object might have a "continuous" path
> property that encodes thousands of individual x-y location values, but
> "discrete" properties for setting the color and thickness of the line. A
> "watercolor stroke" graphic object might have multiple "continuous"
> properties (e.g., path, speed, pressure) in order to graphically mimic
> the diffusion effects that occur when a real paint brush is moved in a
> similar manner.
>
>
>> Appendix F (Comparison 1.0 to 2.0): The page it goes to is marked as
>> Appendix B, rather than F. Perhaps that isn't edited until later?
>
> JR: Editorial. Thanks catching that. Jeanne: Can you fix?
>
>
>> There was another point about A.3.4.1/2, but that is corrected in the
>> more recent draft.
>>
>> Anyway, that was my first impressions, hopefully I'm on the right
>> track? I have a (mild) bias in thinking about web-based CMSs, which
>> might explain where I'm coming from in some cases.
>>
>> I'll check what TinyMCE does for B.1.2.1 (transformations) this week
>> as well.
>>
>> Kind regards,
>>
>> -Alastair
>>
>
> JR: That was actually remarkably painless :) I think we're making progress.
>
> 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 Friday, 11 June 2010 16:40:35 UTC