More ATAG comments

General comments on Part A
--------------------------
Every Part A checkpoint starts with 'For the authoring tool user 
interface,...'

This is hard to parse at the start of the sentence, and is implicit 
anyway. We know it's to do with Authoring Tools. This is ATAG. We know 
its referring to the user interface. this is section A.

I think that its removal would improve things:

'Document how the authoring interface makes use of existing 
accessibility architectures.' is a lot easier to parse than 'For the 
authoring tool user interface, document how the authoring interface 
makes use of existing accessibility architectures.'

That was probably the worst example, being entirely redundant, but they 
would all be improved for its removal.

'Ensure that previews emulate the accessible rendering features of 
target user agents.' is more understandable than 'For the authoring tool 
user interface, ensure previews emulate the accessible rendering 
features of target user agents.'

Where it really does need adding, construct as an active action-object 
comand. E.g. instead of
'For the authoring tool user interface, maintain consistency.'
...try...
'Maintain the consistency of the interface'
...or even...
'The interface must be consistent'


'For Web-based authoring tool user interface functionality: Meeting 
Checkpoint A.0.1 will serve to meet this checkpoint.'

This always comes after the list of success criteria, which means if 
that's what I am developing, I have to read through the other success 
criteria before I realise that they don't apply -- a frustrating reading 
experience. Also, the phrase 'user interface functionality' is redundant 
and just makes it harder to parse.

Suggest that the success criteria for each checkpoint be restructured 
along the lines of

For web based authoring tools:
  1. Meeting checkpoint A.0.1 fully satisfies this checkpoint.
For all other authoring tools:
  1. blah
  2. blah blah



Comments on part B
------------------
B.1.2
http://www.w3.org/WAI/AU/2006/WD-ATAG20techs-20060711/tech2.html#check-leave-access-content 
Techniques for B.1.2. The 'sufficient for (a)' and 'sufficient for (b)' 
statements are confusing. They are just 'sufficient' (because achieving 
either (a) or (b) is sufficient for success).

B.2.4 looks here as if success criterion 1 says that an authoring tool 
can happily not offer text alternatives for non text objects. Is this right?
Also, isn't success criterion 1(a) the same as B.2.5.-1(a)?
Also, not sure that the logic of these criteria works. Does it allow for 
the situation of a new object which needs a text alternative adding? Can 
a blank field be offered which must be filled before the object can be 
published? It would be good to make this explicit.

B.3. "leverage the existing knowledge and skills of authors;" - 
'leverage' is jargon (at least, it is when used as a verb). Don't use.

What's the difference between B3.1-1 and B.3.3?



Comments on Content Type-Specific WCAG Benchmark
------------------------------------------------
OK, I now get why this should be in this document (rather than linked to 
as a separate page). It's really important and is pretty integral to any 
authoring tool that doesn't just stick to vanilla HTML and still images, 
i.e. most of them. So if an authoring tool developer wants to allow his 
users to publish Flash, mp3s, movs etc. as embedded page content (as an 
object), they are presented with what appears to be an enormous 
stumbling block, to whit: 'when a WCAG Techniques document does not 
already exist for a content type, the claimant may publish their own 
Benchmark document.'

So lets look at B.1.1

B.1.1 Support content types that enable the creation of content that 
conforms to WCAG. [Priority 1]
Success Criteria:
1. Any authoring tool that chooses the content type used for publication 
on the Web for the author *must* always choose content types for which a 
published content type-specific WCAG benchmark document exists.
2. Any authoring tool that allows authors to choose the content type 
used for publication on the Web *must* always support at least one 
content type for which a published content type-specific WCAG benchmark 
document exists and must always give prominence to those content types.

Yikes. Okay, so I think this means that I can allow users to link 
through to a DOC, a PDF or download a movie or MP3 audio file, without 
this being an issue. Content type isn't specified in the page. I'm 
assuming that we're not talking about the content type passed by the 
server at the moment of download... is this right? Or is it anything 
that isn't text/html, regardless of whether its embedded in a page or 
simply linked to?

The techniques covering this are...
Technique B.1.1-2.1 [Sufficient] : Whenever the author is given the 
option to choose a content type, providing at least one of the content 
types has had a content type-specific WCAG benchmark (referenced in the 
ATAG 2.0 conformance profile). Also, giving prominence in the user 
interface (i.e., listed ahead of other content types, listed on the 
first page of choices, etc.) to content types with benchmark documents.

But what I, hypothetical web-based authoring tool developer, want to 
know is, if I allow users to put mp3s, movies or documents (word, pdf) 
for download... have I failed? Flash? You really expect me to write a 
benchmark with little support on how to do it for my commonly used 
content-type?

I need to understand this before I can start considering how to support 
other people's understanding of it, and I'm not convinced I do. Am I 
just being a bit dense? Maybe B.1.1 just says 'Support SMIL and SVG and 
promote them above other technologies to your users because they have 
accessibility features that other techs don't'. But if so then it's not 
very clear...

Does it, for example, just mean that the tool should comply with 
technique 17 in the list entitled 'Prompting for Various Types of 
Accessibility Information' in Technique B.2.1
http://www.w3.org/WAI/AU/2006/WD-ATAG20techs-20060711/tech2.html#check-prompt-assist-user


Regards to you all

Liam McGee
www.communis.co.uk

Received on Wednesday, 10 January 2007 18:16:59 UTC