Revised response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0

Dear Anne van Kesteren:

Thank you for acknowledging our response to your comments on the 24
February 2009 Last Call Working Draft of Accessible Rich Internet
Applications (WAI-ARIA) 1.0
(http://www.w3.org/TR/2009/WD-wai-aria-20090224/). Because your
acknowledgement indicated you were not satisfied with our action and / or
provided additional useful information, we reopened the comments to see if
there was further work that could be done related to that comment. We
enclose an updated response to your comments. In most cases we believe the
updated response should address the concerns you raised in your
acknowledgement. In some cases, however, we recognize that you still will
not accept our disposition. If we do disagree, your comments will be
reviewed during the transition meeting with the Director when we seek to
advance the document to the next stage of maturity.

Please review our updated resolutions for the following comments, and
reply to us by 9 December 2010 to say whether you now accept them. If we do
not hear from you by that date, we will mark your comment as "no response"
and close it. If you need more time to consider your acknowledgement,
please let us know. Although you acknowledged our response before, because
of the updated response we need a new acknowledgement from you to record
whether you now agree or disagree with our updated response. Note that only
comments that we reopened are included below; any other comments which you
previously acknowledged are still recorded as you last saw them. You can
respond in the following ways:

* If you have a W3C account, we request that you respond online at
http://www.w3.org/WAI/PF/comments/acknowledge?document_version_id=1;

* Else, by email to public-pfwg-comments@w3.org (be sure to reference our
comment ID so we can track your response). Note that this list is publicly
archived.

Please see below for the text of comments that you submitted and our
updated resolutions to your comments. Each comment includes a link to the
archived copy of your original comment on
http://lists.w3.org/Archives/Public/public-pfwg-comments/, and may also
include links to the relevant changes in the Accessible Rich Internet
Applications (WAI-ARIA) 1.0 editors' draft at
http://www.w3.org/WAI/PF/aria/20101202/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to 3.3.2 of
the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-pfwg-comments@w3.org. Formal objections will be reviewed during
the candidate recommendation transition meeting with the W3C Director,
unless we can come to agreement with you on a resolution in advance of the
meeting.

Thank you for your time reviewing and sending comments. Though we cannot
always do exactly what each commenter requests, all of the comments are
valuable to the development of Accessible Rich Internet Applications
(WAI-ARIA) 1.0.

Regards,

Janina Sajka, PFWG Chair
Michael Cooper, PFWG Staff Contact


Comment 13: Name Computation
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0003.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.1. Name Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#namecomputation>
Status: Alternate action taken

-------------
Your comment:
-------------
Two comments:

 1. It does not define how to concatenate the results. Simple string
concatenation?
 2. "text equivalents for nodes" is not linked. Would be nice if that was
consistently done.

--------------------------------
Response from the Working Group:
--------------------------------
Section "5.2.7.1. Name Computation" references the "Text Alternative
Computation" following it.  "5.2.7.2. Description Computation" also
references the "Text Alternative Computation" section, where the
computation is triggered by the aria-describedby attribute.  We will add
text to clarify these references.

Regarding concatentation, the paragraph just below step 3, after the note,
describes how strings are joined.  Quoting the part relevant to
concatentation:

> At each step of the algorithm, an implementation will trim the existing
text
> equivalent string and the string to be added, then join those two
strings
> with a single space.

----------------------------------------------------------------------


Comment 15: Text Equivalent Computation
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0005.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.3. Text Equivalent Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textequivalentcomputation>
Status: Proposal not accepted

-------------
Your comment:
-------------
This algorithm (section 4.2.7.3) has many issues:

 1. "hidden" is not defined. In the DOM nothing is hidden. I'm assuming
you might mean not visible on screen, but that is a very hard concept to
define and implement. This needs to  be far more concrete to be
implemented.
 2. The use of DOM attributes is inconsistent with HTML5. Simply using
attributes would suffice here I think and be more clear.
 3. The third bullet point of 2A is not clear at all and saying it is
covered by the "appropriate specification for that markup" is not true.
HTML4 or HTML5 does not cover what seem to be hinting at here.
 4. "Additional contribution of user-entered data" needs a much more
precise definition as well. "appended after" is also not particularly clear
here.
 5. 2C leads to infinite recursion in this scenario:

  <span id="a">
   <span aria-describedby="b">X</span>
  </span>

  <span id="b">
   <span aria-describedby="a">X</span>
  </span>

    and something points to either #a or #b if I'm reading this
correctly.
 6. 2D is also not very clear. What to do for SVG where tooltips can
contain markup?
 7. Point 3 is even less clear. List style bullets are not generated text.
Whitespace normalization needs to be defined here.

In general this algorithm seems very much over engineered for something
that should be very simple. Getting this interoperably implemented is a
gigantic task for very little benefit so it is unlikely it will ever
happen. Also, I thought this draft was not about implementation
requirements?

--------------------------------
Response from the Working Group:
--------------------------------
Regarding hidden elements, we had responded about "hidden" in two different
places.  One part of our response, as you noted, was about the equivalence
of aria-hidden and the HTML5 hidden attribute.  The other part was about
the definition of "hidden".  To put this into context, the initial comment
about "hidden" was:

> 1. "hidden" is not defined. In the DOM nothing is hidden. I'm assuming
you
> might mean not visible on screen, but that is a very hard concept to
define
> and implement. This needs to be far more concrete to be implemented.

In another part of our response, we wrote:

> We will change the definition of hidden to:
> 
> Indicates that the element is not visible or perceivable to any user as
> implemented by the author.

The definition goes on to say that an element is considered hidden when it
or one of its ancestors has an aria-hidden attribute with a value of
"true".  The full text is available in the spec at this location:
http://www.w3.org/WAI/PF/aria/terms#def_hidden

As you noted, hidden does not mean that the element is not in the DOM. 
Nonetheless, for the purpose of computing a text alternative, a UA will not
include a hidden element.  To be concrete, the UA will ignore elements
marked with aria-hidden="true", or with the HTML5 "hidden" attribute, as
well as their descendants in the DOM tree.

With respect to host language text alternatives, we wrote:
> On the text alternative computation clarity issue, we agree and will
add
> links to the following explanatory parts of the HTML specs:
> 
> * HTML 4 "How to Specify Alternate Text"
> http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.8
> * HTML 5 "Requirements for providing text to act as an alternative for
> images" http://dev.w3.org/html5/spec/Overview.html#alt

You replied:

> In my comment I said that neither HTML4 nor HTML5 defines this. So
linking to
> them is not going to help. And if this is supposed to be for
implementors --
> as that is what it seems like -- pointing at requirements for authors
will
> not help.

The initial comment was:

> 3. The third bullet point of 2A is not clear at all and saying it is
covered
> by the "appropriate specification for that markup" is not true. HTML4
or
> HTML5 does not cover what seem to be hinting at here.

We are unclear as to why you think the referenced sections do not define
this.  Step 2A states that if neither aria-label nor aria-labelledby are
given in the markup, that the UA is to use host language text alternative
attributes and/or elements.  Using html4 as an example of a host language,
the relevant attributes and elements are the alt attribute and the label
element.  Thus, for html4, the UA will look for and use the alt attribute
or the label element, as appropriate (alt is used with img elements, while
label is used with form control elements).

As for the purpose of the ARIA text alternative computation: yes, it is
for UA implementors.  But, it appears here as a guide for authors.  Authors
create the markup that the UA will use to compute the text alternative. 
Knowing how that computation proceeds will inform them in terms of
achieving the intended textual alternative.

----------------------------------------------------------------------


Comment 18: 5.2.4 Value
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0008.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.4. Value <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#propcharacteristic_value>
Status: Proposal not accepted

-------------
Your comment:
-------------
I think for authors it would make much more sense here to reuse datatypes
from HTML or SVG.

Speficially NMTOKENS and IDREFS do not work as described in HTML context
because HTML does not do whitespace normalization of attribute values.
Neither does the DOM for that matter. E.g.

  aria-labelledby="a
b"

does not match the IDREFS production. It is highly unlikely anyone would
implement it that way though and it is also confusing to authors because
e.g.

  headers="a
b"

does work perfectly fine and as expected.

Similar attributes that take "true" and "false" as values in HTML such as
contenteditable="" and spellcheck="" also take the empty string (meaning
true) and match in an ASCII case-insensitve way. They do not take 0 and 1
as allowed values. I think it would be much better to align with that.

--------------------------------
Response from the Working Group:
--------------------------------
== Response to the concerns raised in your acknowledgement ==

We acknowledge and share your concern about introducing differences in
ARIA value types between different platforms / host languages. But we
intend and expect ARIA to be supported in many host languages (HTML, SVG
and DAISY are on the immediate radar, and others have been considered). In
your original comment you expressed concerns about the impact a single
(XML-centric) model would have in integration in HTML. If we were simply to
adopt the HTML 5 syntax wholesale, we would introduce the same problem your
reacted to for other languages. So we introduced the model we now have, in
which ARIA value types in the spec are abstracted and mapped to host
language models. While more complex, this allows ARIA to be integrated as
seamlessly as possible into a given host language.

This does introduce more complexity to the ARIA specification, and sets up
a situation in which equivalent ARIA features are not lexically identical
between host languages. That in turn could create authoring, evaluation,
and user agent implementation challenges. However, to favor the
requirements of a single host language could introduce larger problems in
wide-scale adoption of ARIA. Therefore we have to live this situation.

To reduce some of the confusion caused by our "boolean" value type, which
does not map to native boolean values in many host languages, we have
renamed the name of the type to "true/false". As before, this generally
maps to a token data type with an enumeration constraint. 

== Original Response ==

We have made ARIA attribute types abstract without inherent formats. Host
languages would use corresponding types from that language for each ARIA
type. We are providing a recommended mapping from the abstract types in
ARIA to concrete types in known host languages. In this way, attribute
value syntax and processing rules come from the host language, not the ARIA
specification. 

Note that our recommended mappings for HTML are fairly straightforward,
except that ARIA boolean attributes are token attributes (accepting values
of "true" and "false", not HTML boolean attributes (where false can only be
declared by omitting the attribute). This is because of the way these
attributes have already been implemented and for greater portability
between host languages.

== New Response ==

We do not agree with your concerns about what might happen. WAI-ARIA has
broad user agent implementation support of these values in Internet
Explorer 8 and 9, Firefox 3, and Safari 4 and 5. There is also existing and
continuing support in a variety of JavaScript libraries and assistive
technologies, as well as hundreds of other products. We do not agree that
this type needs to change, and believe your proposal to allow host language
remapping of ARIA data types would unnecessarily break implementations. 

As you requested, this comment will be treated as a Formal Objection and
considered by the Director when we request transition of the specification
to Candidate Recommendation.

----------------------------------------------------------------------


Comment 23: 7.2. All WAI-ARIA in DOM
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0013.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7.2. All WAI-ARIA in DOM <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#ua_dom>
Status: Alternate action taken

-------------
Your comment:
-------------
The requirement in this section is redundant with requiring a DOM
implementation in the first place. I.e. a conforming DOM implementation
exposes all attributes and values as they are in syntax.

--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comments. The intent of this section is to ensure that
DOM implementations expose all ARIA-related content attributes so that they
may be accessed by assistive technologies. We have clarified this in the
specification by changing the text to say:

A conforming user agent which implements a Document Object Model that does
not conform to the W3C DOM specification MUST include the content attribute
for role and its <a href="#roles_categorization">WAI-ARIA role values</a>,
as well as the <a href="#states_and_properties">WAI-ARIA States and
Properties</a> in the DOM as specified by the author, even though
processing may affect how the elements are exposed to accessibility APIs.
Doing so ensures that each role attribute and all WAI-ARIA states and
properties, including their values, are in the document in an unmodified
form so other tools, such as assistive technologies, can access them. A
conforming W3C DOM meets this criteria.

----------------------------------------------------------------------


Comment 24: 7.3. Web Application Notification of DOM Changes
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0014.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7.3. Web Application Notification of DOM Changes <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#ua_domchanges>
Status: Alternate action taken

-------------
Your comment:
-------------
This section seems to contradict the entire idea that changes are driven by
script from authors and not by the AT. This fundamentally goes against the
whole idea that ARIA is non-intrusive and just an "add-on". Since this is
nowhere else described I assume this is in error and suggest that this
section be removed.

--------------------------------
Response from the Working Group:
--------------------------------
The same need and requirement remains, but we've adjusted the wording to
discourage external manipulation of the DOM by assistive technologies.

Received on Thursday, 2 December 2010 22:27:33 UTC