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

I know it is late but I thought it might be worth something anyway.


In general I have to say that these committee answers are not really  
helping productive discussion. The answers are also not always complete  
and sometimes talk about different things. Actual conversation on the  
mailing list would surely help. How would you say, the WG doesn't seem  
very accessible ;-)


On Thu, 17 Jun 2010 20:25:10 +0200, Janina Sajka <janina@a11y.org> wrote:
> 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:
> --------------------------------
> The entire text equivalent calculation section has been reworded and  
> these
> issues were clarified in that rewording.
>
> In response to your acknowledgement, we did have a misleading link that
> referenced you to an outside document. Nevertheless, the section we
> intended you to review was just below, at
> http://www.w3.org/WAI/PF/aria/20100616/roles#textalternativecomputation.  
> We
> are correct the misleading link.

"5.2.7.1. Name Computation" says something is defined below, but then it  
does not reference it. Below is talk about "Description Computation" and  
"Text Alternative Computation". At this point I really have no idea what  
this section is trying to say.

"5.2.7.2. Description Computation" also still does not define what  
"concatenating" means. And although you changed "text equivalents for  
nodes" into "text alternatives for nodes" it is not linked nor have you  
given a reason for why this is not the case.

How is this addressing my comment in the slightest?


> 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:
> --------------------------------
> == Responses to the concern raised in your acknowledgement ==
>
> On aria-hidden, we will change the author requirement from a SHOULD to a
> MUST. We consider that the hidden attribute in HTML5 has strong native
> semantics that are equivalent to aria-hidden and therefore would take
> precedence. This will be documented in the expected HTML implementation
> guide.

This seems unrelated to my comment.


> 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

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.


> 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: Alternate action taken
>
> -------------
> 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.

I don't think this is acceptable. HTML and SVG share many data types  
already and will only converge more over time. DAISY will be obsoleted by  
an HTML-based book format surely so I do not think that should be  
considered so strongly. It is also not developed by the W3C.

WAI-ARIA should tackle this issue and clearly define the syntax rules  
rather than leaving it for other people (such as me) to sort out. If still  
possible I would like to raise a Formal Objection against this WG decision  
for the reasons mentioned in these two paragraphs.


> 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: Accepted proposal
>
> -------------
> 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.

While clarified, you kept the requirement, which means you did not accept  
my comment. Please clearly indicate you rejected my comment if still  
possible.


> 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:
> --------------------------------
> We see this feature as necessary to ensure the robustness of WAI-ARIA and
> accessible web applications. However, since DOM mutation events have  
> known performance considerations, we are modifying the wording to remove  
> specific references to DOM mutation events. Satisfaction of this  
> requirement may be achieved with DOM mutation event support, or with  
> other future standards
> currently in discussion. We have illustrated the need for alternate input
> devices, such as voice recognition systems, to modify a web application's
> WAI-ARIA states and properties in a device independent way and have the
> application respond to these changes.

It seems this section is premature then and should be removed. As a web  
developer I have no idea how to implement the requirements in this section.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 17 August 2010 14:40:30 UTC