Re: Current ATAG draft

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 Tuesday, 8 June 2010 20:40:12 UTC