RE: EOWG: Preparation for Friday 16 January 2009 teleconference

 Hello Shawn,

I am planning to participate in today's call but nevertheless my
comments in electronic form. It is hard to review 3 big documents in a
realtively short period of time so I do my best by skimming thru the
docs. Also it would be good if you e.g. allocate the next week's telco
for the same subject or if that is not necessary allow more time for
feedback and comments via e-mail.

ARIA Overview page does not contain WAI-ARIA User Agent Implementation
guideline. 

Generally on ARIA and WAI pages, I still don't see relationship between
WCAG and ARIA in any place. IMO ARIA is no less important that WCAG.
UAAG work hand in hand with WCAG and now WAI-ARIA User Agent
Implementation guideline has been drafted. So this overall picture needs
to be updated.

WAI-ARIA 1.0
============
Abstract references ARIA Overview page. Should it instead give the link
directly to ARIA suite with or without mentioning ARIA Overview? ARIA
Overview is not meant for any specific audience and reader of the
overview may or may not read ARIA spec. But once you are in ARIA spec,
sure enough you are going to read spec's introduction that provides
information similar to ARIA Overview page.

Introduction has a sentence: "Assistive technology software can
transform the presentation into a format more suitable to the user, and
can allow the user to interact in different ways than the author
designed." Good to have some example here of what suitable format may be
and what would be different ways of interaction.

It is good to start Introduction with one paragraph of the general
problem statement (borrow something from ARIA Overview). Othrwise
Introduction jumps to what ARIA is offering without explaining what are
the problems that ARIA is addressing.

1.2 Use cases. One would expect a bullet list of use cases here. The
current material presentation hardly looks like use cases, is not
sistemised and not labelled in any way.

3. I would change the title to ARIA Requirements. The current title
looks a bit odd from the table of content. Also each chapter is anyway
labelled as normative or informative.

Can anything be done with the diagram in 4.4? If you print the whole doc
the diagram is unreadable. Even id diagram is scaled and printed to A4
it is rather hard to concentrate on a very small font. Place boxes
closer and make them bigger? Stretch diagram vertically so that it does
not require so much horizontal scrolling?

Should definition of roles be moved to appendix and be labelled as
normative? 

No intro text between 5 and 5.1?

States and roles are colour coded. I don't see the legend explaining
what is marked as yellow, grey or blue? Also is colourcoding absolutely
necessary? My experience is that it is always good to have as
black&white specification as possible. Most people use BW printers to
print large docs. 

WAI-ARIA 1.0 User Agent Implementation Guide
============================================

Not all links in the table of content work. Some jomp to the top of the
spec.

The abstract is too short and this document it NOT YET part of ARIA
suite as described in ARIA Overview and noted by me earlier in this
mail.

Introduction does not describe relations of this doc to ARIA spec.
generally the top of introduction lacks some general text stating the
problem this document is addressing. Also it is important to state that
the basics are explained in ARIA and reader of this document is supposed
to be familiar with ARIA spec.

It would be good also to give a status of this document. It does not
seem to be a normative document. Perhaps can say that this is supporting
document to ARIA spec and the target audience dor this doc is user agent
developers.

In the introduction it is good to have some reference to where these
APIs can be found
ATK/AT-SPI on Linux
MSAA/IAccessible2 on Windows
At least MSAA has a reference link just before 4.3. need to have it in
the intro.

Again colour coding does not have any legend.

Last paragraph before 2.2. What is Gecko document? It is neither linked
nor explained.

2.2 bullet 5. This is the first time AT occurs but the acronym is not
explained.

2.3 title, replace AT with Assistive technology

3. Mapping ARIA to APIs. Accessibility APIs? If so, it needs to be
stated in the title. This is important.

Why managed stated deserve a separate paragraph and do not come under
the paragraph 3?

Chapter 4 has no intro whatsoever. Oddly enough the title is "managed
states" but this chapter has zero occurrence of this term. Is the title
correct?

WAI-ARIA Best Practices
=======================

Unlike two other docs this one has a good abstract. This is probably a
credit to Lisa P. My only comment is, what is a best practice? "This
document specified best Practices..." Best Practices is a title and
there is a meaning to it. I would replace the first sentence of the
Abstract with the first sentence from the Introduction (with slight
modification)--> "The WAI-ARIA Best Practices guide provides readers
with an understanding of how to use WAI-ARIA to create an accessible
Rich Internet Application."

Also the word "provide" is used too frequently.

Chapter 2 mentions "existing ARIA-enabled widget library". I wonder if
such libraries exist publicly? I would remove the word "existing"
alltogether. The message will not suffer any loss.

Again colour coding has no legend.

Unify the titles, either providing/setting/allowing across the doc or
provide/set/allow. Now it is a mix.

In chapter 9 what does it mean "Placeholder for Local Index"?

Typo in the first sentence of chapter 10.

In chapter 10 I would remove two sentences that have recommendations to
reuse existing libraries. Firstly it is a matter of ones choice to reuse
someone's work or not. Secondly, being true to the spirit of public
standards, some existing implementations should not be promoted by the
standards. I would write chapter 10 in the following way:

Writing rich internet applications is much more difficult than writing
in HTML. It requires extra effort to ensure your application runs in
multiple browsers and supports WAI-ARIA.  Authors of rich internet
application widget libraries will have to go through:

* extensive testing with assistive technologies
* cross browser testing 
* testing to ensure that the widgets respond to desktop settings 
* testing to ensure that the widgets match a common keyboard style guide


There are publicly available UI component libraries which have already
implemented WAI-ARIA, e.g. Dojo Toolkit Dijit library. (Any other? Who
can guarantee quality assurance of Dojo Tookit to comfortably reference
it in W3C standard???) Reusing such libraries is one way to start
developing accessible rich internet applications.

That's all I've got after scrolling 3 docs.

Regards,
Anna


>-----Original Message-----
>From: w3c-wai-eo-request@w3.org 
>[mailto:w3c-wai-eo-request@w3.org] On Behalf Of ext Shawn Henry
>Sent: Thursday, January 15, 2009 12:13 AM
>To: EOWG (E-mail)
>Subject: EOWG: Preparation for Friday 16 January 2009 teleconference
>
>
>EOWG,
>
>The agenda for the 16 January 2009 teleconference is updated 
>at: http://www.w3.org/WAI/EO/#agenda
>
>Please take some time before the teleconference to review the 
>in-progress WAI-ARIA documents. Be prepared to comment on them 
>from an education and outreach perspective (not the technical 
>content), such as the introductions and overall flow.
>
>The editors would also like some feedback on:
>a. Is the overall progression from top to bottom logical and 
>understandable?
>b. As you read through them, do you feel you need some 
>background to understand it that is missing?
>
>Regards,
>~Shawn
>
>-----
>Shawn Lawton Henry
>W3C Web Accessibility Initiative (WAI)
>e-mail: shawn@w3.org
>phone: +1.617.395.7664
>about: http://www.w3.org/People/Shawn/
>
>

Received on Friday, 16 January 2009 10:41:29 UTC