Current ATAG draft

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. 

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!

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.


    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?


    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).

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

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?

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

-- 
Alastair Campbell         |  Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer

(c) Nomensa Ltd, King William House, 13 Queen Square Bristol BS1 4NT, 
GB 771727411, C#4214477

Received on Tuesday, 8 June 2010 12:12:51 UTC