FW: EOWG: Preparation for Friday 16 January 2009 teleconference

 Dear PF members,

We in Education and Outreach group were actioned to review some of ARIA docs and I was adviced by Shawn Henry to send by bunch directly to PF list. That's what I am doing now, please have a look.

Best regards,
Anna Zhuang

>-----Original Message-----
>From: Zhuang Anna (Nokia-D-MSW/Tampere)
>Sent: Friday, January 16, 2009 12:40 PM
>To: 'ext Shawn Henry'; EOWG (E-mail)
>Subject: RE: EOWG: Preparation for Friday 16 January 2009
>teleconference
>
....
>
>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
>
>

Received on Wednesday, 11 February 2009 07:57:09 UTC