[ATAG20] feedback

http://www.w3.org/TR/ATAG20/

Initially I drafted this reply as a linear response to the document.
I've decided to break out a few sections, otherwise the quoted text is
generally in document order.

Trademark misspellings:

> (e.g. GNOME desktop on Linux, MacOS, Windows, etc.)

s/MacOS/Mac OS [X]/g

> (e.g. Android, Blackberry, iOS, Windows Phone, etc.)

s/Blackberry/BlackBerry/g

> AXAPI for Mac OSX applications,

s/Mac OSX/Mac OS X/g

> Gnome Accessibility Toolkit API for Gnome applications

s/Gnome/GNOME/g

Example-indicator ... etc. lists:

This section is a list of instances where the document used `such as`,
`including`, or `e.g.` to start a list which ends with `etc.` -- they
really shouldn't be used together, pick one (drop the other, generally
i'd suggest dropping `etc.`).

> such as menus, button bars, status bars, user preferences, documentation, etc.

s/documentation, etc/and documentation/

> (e.g. by plug-ins, user modifications, etc.).

s/, user modifications, etc./ or user modifications/

> (e.g. keyboard navigation, find functions, display preferences,
> undo features, etc.)

> (e.g. documentation, search functions, etc.).
> (e.g. source code, content renderings, etc.)
> (e.g. keyboard shortcuts, text search, etc.)
> (e.g. by plug-ins, user-defined templates, user modifications of default settings, etc.).
> (e.g. checking tools, repair tools, tutorials, documentation, etc.).
> (e.g. attribute values, etc.)
> (e.g. clip art, synchronized media, widgets, etc.)
> (e.g. clip art, synchronized media, widgets, etc.)

> (e.g. private intranets versus public websites, monolingual sites
> versus multilingual sites, etc.).

> (e.g. a photo editor, a CSS editor, a status update field in a
> social networking application, etc.)

> (e.g. via scripting, macros, etc.)
> such as content authors, designers, programmers, publishers, testers, etc.
> (e.g. online tracking pages, etc.)
> such as Windows, Mac OS, Java Virtual Machine, etc.

> (e.g. typing markup into a source editing-view,
> writing captions for audio, etc.).

> (e.g. applying a template, automatically correcting markup errors, etc.).

> includes help, manuals, installation instructions,
> sample work flows, tutorials, etc.

> (e.g. GNOME desktop on Linux, MacOS, Windows, etc.)
> (e.g. Android, Blackberry, iOS, Windows Phone, etc.)
> includes, but may not be limited to, ... (e.g. Java), etc.

> (e.g. MSAA, IAccessible2 and UI Automation for Windows applications,
> AXAPI for Mac OSX applications, Gnome Accessibility Toolkit API for
> Gnome applications, Java Access for Java applications, etc.).

> (e.g. items in a list, items in a menu, buttons in a toolbar,
> all components on a dialog box, etc.)

> For example: (a) keyboard shortcut to a top-level menu item to
> display a sub-menu, (b) keyboard selection on a button to display a
> dialog box, (c) mouse click on a checkbox to enable previously
> disabled sub-items, etc.

> (e.g. the set of all help documentation examples, the set of all
> templates, etc.)

> (e.g. elements, attributes, widgets, etc)

> (e.g. menu items, form fields, etc.)

End of (including|such as|e.g.)...etc. Note that if you omit `etc.`
from all these cases, you avoid the chance of omitting the `.` at the
end of `etc.` as perpetrated in the instance immediately preceding
this paragraph.

Inconsistent use of `e.g.` with/without `,` for a singular examples:

> (e.g., if text alternatives for non-text content are required)

This is a rare instance where you have a comma after your `e.g.`, the
next instance does not:

> (e.g. if attributes for defining text alternatives are not available)

There are rules for their use, which this document ignores.

http://blog.editage.com/?q=taxonomy/term/348
Basically says that you're missing a lot of commas (remember, w3 is
en-US, as is the US DoEd which according to a note in this document
was a sponsor).

Gerands:

 -- Three cases where they should be used --
>    Multiple author roles: Some authoring tools include multiple author roles,
> not to the view provided to any particular author role.
> ... available to any author role where it would be useful.

s/author roles/authoring roles/g

 -- Three cases where they should not be used --

>        manual repairing:
>        semi-automated repairing:
>        automated repairing:

s/ing//g

Typographical errors:

> (see Part A Conformance Applicability Notes,

s/,/ and / ?

> The authoring tool user interface includes mechanisms to make keyboard
> access more efficient than sequential keyboard access . (Level AA)

s/access ./access./

> Rationale: By guiding authors from the outset toward the creation
> and maintenance of accessible web content (WCAG) ,

s/ ,/,/

> and demonstrating the importance of accessible web content (WCAG) .

s/ ././

>        Note: Under these conditions, some templates will result in
> completely empty documents, which are considered accessible by default..

s/.././ ?

General feedback:

>    ATAG 2.0 recommends that authoring tools be capable of producing
> web content that conforms with WCAG 2.0.

s/with/to/

> If a conformance claim is made for a web-based authoring tool,
> the claim must cite the user agent.

What do you mean `cite`?

> Non-web-based authoring tool user interfaces follow user interface
> accessibility guidelines for the platform. (Level A)

This document isn't using RFC words. I expect a `should` or `must`
before `follow`, the sentence feels awkward without it.

>    Note: If a conformance claim is made, then the claim must cite
> the accessibility guidelines followed.

`cite` how? (An example or formal structure would be nice, is
"Supports WCAG2" sufficient? Should it be "Supports <url> level X"?)

>    Note: If a conformance claim is made, then the claim must cite
> the platform accessibility service(s) implemented.

`cite` is a weird word, I think you want `list` here.

> Guideline A.2.1: (For the authoring tool user interface)
> Make alternative content available to authors.
> [Implementing A.2.1]

> Rationale: Some authors require access to alternative content in
> order to interact with the web content that they are editing.

Some? Don't all authors need to be able to access alternative content?

> If an editing-view renders non-text content with programmatically
> associated text alternatives,

`programmatically` sounds wrong, to me <script> is programmatic. I
think you mean `structurally`.

> then the text alternatives can be programmatically determined. (Level A)

> A.2.1.2 Alternatives for Rendered Time-Based Media:
>    (a) Alternatives Rendered: Alternatives for the time-based content
> are also rendered; or

Always rendering captions doesn't seem like the right requirement. I
think you want `can be rendered` not `are also rendered`. Being
accessible doesn't mean burning captions into content (I just watched
a movie last night where the captions were initially projected into
the speakers below the screen... -- and I needed the captions).

Note that the text for (b) is nicer, it says `has the option to...
render the alternatives`, which is really what should be offered in
(a).

>    (b) User Agent Option: Authors have the option to preview the
> time-based content in a user agent that is able to render the alternatives.


> Keyboard access to the authoring tool can be customized. (Level AAA)

I seem to recall writing feedback on this somewhere, but basically,
I'm not sure I agree with this requirement. It makes more sense for a
platform accessibility agent (OS or third party) to offer a consistent
UI for customizing keyboard access than having dozens of applications
each inventing their own incompatible models.

> Authoring tool user interface components can be presented with any
> associated keyboard commands. (Level AAA)

What does `presented` mean? (This sentence took me 5 minutes to decipher.)

~There should be a way for a user to determine the associated keyboard
commands for authoring tool user interface components.~ ?

> A.3.2.4 Content Edits Saved (Extended):

> The authoring tool can be set to automatically save web content edits
> made made using the authoring tool. (Level AAA)

s/made made/made/

> A.3.4.2 Navigate by Programmatic Relationships:

I've already commented that I don't like `programmatic`. You might
mean `structural` or `DOM associated` or similar.

Based on the context, I think `structural` is correct.

>    (e) Case Sensitive: The search can be in both case sensitive and
> case insensitive modes.

You don't define `case sensitive`. Please be aware that this area runs
into I18n issues.

> Guideline A.3.6: (For the authoring tool user interface)
> Manage preference settings. [Implementing A.3.6]

> Rationale: Some authors need to set their own display settings
> in a way that differs from the presentation that they want to
> define for the published web content.

> Providing the ability to save and reload sets of keyboard and
> display preference settings benefits authors who have needs
> that differ over time (e.g. due to fatigue).

> A.3.6.3 Apply Platform Settings:
> The authoring tool respects changes in platform display and
> control settings made by authors. (Level AA)

If the user has already specified custom settings in the application,
then this requirement seems brittle. It should be compatible with the
user being able to specify custom settings in the application.

> A.3.6.4 Multiple Sets:
> If the authoring tool includes display and/or control settings,
> then authors can save and reload multiple sets of these settings.
> (Level AAA)

I think you mean complete sets as opposed to subsets of settings. And
that multiple just means <app-full-settings-for-morning.settings> and
<app-full-settings-for-evening.settings> and not <app-editor.settings>
/ <app-previewer.settings> -- I think your text sort of implies the
latter, which seems to be overreaching, even for AAA.
> A.3.6.5 Assistance with Preferences:
> If the authoring tool includes display and/or control settings,
> then the authoring tool includes a mechanism to help authors
> configure these settings. (Level AAA)

It sounds like you're asking for a Wizard. If you mean that, perhaps a
`such as a Wizard` would be useful.

> A.4.1.2 Setting Changes Reversible:

> If actions modify authoring tool settings, then one of the following
> is true: (Level A)

Would it be sufficient to have a way to save and restore settings
(with a warning/way to save current settings)?

> PART B: Support the production of accessible content
Part B Conformance Applicability Notes:

>    Author availability: Any Part B success criteria that refer

s/refer/refers/

> to authors only apply during authoring sessions.

s/apply/applies/

> Authoring tools are not responsible for changes to the accessibility
> of content that the author has specified, whether it is author-generated

The use of `specified` here is probably important, but the sentence is
not clear.

Perhaps,

s/specified/merely selected for the purpose of embedding/

> or automatically-generated by another system that the author has specified
> (e.g. a third-party feed).

s/specified/merely selected for use/

I'm not sure whether `merely` is needed, but my initial drafting does
include it...

> to meet the requirements of Part B

>    Features for meeting Part B must be accessible:

s/for meeting/provided to meet/

Should this be s/Part B/the requirements of Part B/ ?

> B.2.2.2 Setting Accessibility Properties (WCAG):
> If the authoring tool provides mechanisms to set web content
> properties (e.g. attribute values, etc.),
> then mechanisms are also provided to set web content properties
> related to accessibility information (WCAG): (Level A to meet WCAG 2.0
> Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA
> success criteria; Level AAA to meet all WCAG 2.0 success criteria)

This blob did not end in a period, s/:/./
-- a note follows the `:` but it doesn't make sense to think of that
as a `list`.

> B.3.2.1 Repair Assistance (WCAG):
> If checking (see Success Criterion B.3.1.1) can detect that a
> WCAG 2.0 success criterion is not met, then repair suggestion(s)
> are provided: (Level A to meet WCAG 2.0 Level A success criteria;
> Level AA to meet WCAG 2.0 Level A and AA success criteria; Level
> AAA to meet all WCAG 2.0 success criteria)

This blob did not end in a period, s/:/./
-- a note follows the `:` but it doesn't make sense to think of that
as a `list`.

> B.2.2.3 Technology Decision Support:

> If the authoring tool provides ... producing ... not provide support ...
> accessible content, then both of the following are true: (Level A)

>    (a) Warning: ...
>    (b) List: From the warning, authors can access a list of
> technologies for which the authoring tool does provide support
> for the production of accessible content.

I'm uncertain how (b) will be remotely useful to the user. If the
application can produce 100 unrelated accessible things and the user
is trying to create a certain 1 thing which is not related to the 100
unrelated accessible things, then other than being forced to have a
somewhat prominent advertisement for unrelated features, I think the
user is being done a disservice.

Two possible ways to address my concern are:
s/technologies/[related|similar] technologies/

> This guideline applies when non-text content is specified by authors
> (e.g. inserts an image).

s/inserts/inserting/

> the authoring tool may only automatically suggest programmatically

You're using an rfc word (`may`) here, which is odd...

>   Note: It is recommended that the accessible options be identified,
> but this is not required.

It's probably better to identify the inaccessible options.

Implementing B.2.4.1
B.2.4.2 Identify Template Accessibility (Minimum):

> If the authoring tool includes a template selection mechanism and
> provides any non-accessible template (WCAG)

`non-accessible` isn't a word (certainly not in common use, under a
million hits), do you have something against `inaccessible` which is
in fact a word...?

> (e.g. clip art gallery, widget repository, design themes)

s/, design/, and design/ ?

> B.3.1.2 Help Authors Decide:

> For checks that require authors to decide
> whether a potential web content accessibility problem is correctly identified

s/whether/whether there is/;s/potential//;s/is correctly identified//

> ..., instructions are provided from the check that describe how to
> make the decision.

s/make the decision/decide/

(and again for the next section)

> For checks that require authors to decide
> whether a potential web content accessibility problem is correctly identified
> ..., the relevant content is identified to the authors. (Level A)

> identification might involve highlighting elements or
> renderings of elements, displaying line numbers,
> or providing instructions.

s/instructions/other instructions/ ?

> For example, the status might be a listing of problems detected
> or a WCAG 2.0 conformance level, etc.

> Rationale: The accessible content support features will be more
> likely to be used if they are turned on and are afforded reasonable
> prominence within the authoring tool user interface.

I don't know that this claim is supportable. Authoring tools back to
the age of time (Netscape Gold) had an alt tag field for images, that
didn't result in accessible content.

> B.4.1.3 Feature Deactivation Warning:
> If authors turn off an accessible content support feature,
> then the authoring tool informs them that this may increase
> the risk of content accessibility problems. (Level AA)

Depending on the UI, this can be an incredibly stupid if not
absolutely inane requirement.

If I have a dialog called "Accessibility Options", and have check
items for various features, then being required to give the user a
warning after they uncheck such an option is just plain stupid.
Start>Shutdown, are you sure you really really want to shut down?
(I've actually seen dialogs which include `really`, sadly.)

A better requirement would be to simply require that the user be aware
that the option they are disabling will affect accessibility -- either
through the UI design itself or via a subsequent warning.

> B.4.1.4 Feature Prominence:

> Accessible content support features are at least as prominent as
> features related to either invalid markup, syntax errors, spelling
> errors or grammar errors. (Level AA)

Having worked with web pages for well over a decade, I can say the
same for invalid markup and syntax errors. Having worked in Europe, I
can say with some level of confidence that spelling errors are
absolutely ignored. As for grammar, people don't even bother looking
at them if they don't pay attention to spelling. As such, this
requirement has no teeth. You should be aware of this. OTOH, there
really isn't any level beyond them to suggest....

> Rationale: Without documentation of the features that support the
> production of accessible content (e.g. prompts for text alternatives,

This doesn't make sense in context. Documentation is unlikely to
include prompts. Perhaps *explanations* of prompts.

> accessibility checking tools),

And *descriptions* or *recommendations* of tools ...

> some authors may not be able to use them.

This doesn't follow.

> Demonstrating accessible authoring as routine practice will encourage
> its acceptance by some authors.

This is a pipe dream and doesn't seem suitable for a standards
document. It's even rather weak given its use of `some`....

> A range of examples in the documentation ... demonstrate accessible
> authoring practices that meet the WCAG 2.0 success criteria.

You're missing a verb or something,
s/demonstrate/should demonstrate|demonstrating/

>        email clients that send messages in web content technologies

s/in/using/



> (e.g. a touchscreen PDA can have a keyboard interface

s/touchscreen/touch screen/

> prompt
>    Any authoring tool initiated request for a decision or piece
> of information from authors.
> Well designed prompting will urge, suggest, and encourage authors.

s/promptings/prompts/ ? This whole thought makes me sick. Typically
prompts just annoy users. Note that this last sentence is missing a
<what>, perhaps "to do the right thing".

>        irreversible actions:

s/irreversible/not undoable/g ? `irreversible` is not a common word,
and its primary results on the web are NSFW.

>        source views: The content is presented in unrendered form

s/unrendered/raw|underlying/ ? `unrendered` seems to be a term limited to FCP.

Received on Tuesday, 2 August 2011 18:45:21 UTC