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

On Tue, 15 Dec 2009 01:33:44 +0100, Janina Sajka <janina@rednote.net>
wrote:
> * 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;

This did not work. Maybe because I'm slightly late? Nevertheless, my
replies below. I omitted the comment if I had no further issue with it.
Wherever I did not omit the comment I am not satisfied with the response
(and give reasoning).


> Comment 12: abstract roles
> --------------------------------
> Response from the Working Group:
> --------------------------------
> We have changed the requirement to state that authors MUST NOT use  
> abstract roles, and that conformance checkers should raise an error. We  
> are also
> adding to the User Agent Implementation Guide error handling procedures  
> for abstract and unknown roles, that they ignore the role.

Why only a SHOULD for conformance checkers?


> Comment 13: Name Computation
> --------------------------------
> Response from the Working Group:
> --------------------------------
> The entire text equivalent calculation section has been reworded and  
> these issues were clarified in that rewording.

What I'm seeing is that the section has been taken out and moved to
another draft. I don't understand the response.


> Comment 15: Text Equivalent Computation
> --------------------------------
> Response from the Working Group:
> --------------------------------
>> 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.
>
> We have added a definition of "hidden" to the glossary
> (http://www.w3.org/WAI/PF/aria/20091214/terms#def_hidden).  In brief, a
> hidden element is one that is not visible nor perceivable to *any* user.
> Use of aria-hidden or CSS visibility:hidden, and display:none mark an
> element as hidden, as does use of aria-hidden="true".

That definition of hidden does not actually define anything as far as I
can tell. If one <div> element is positioning on top of a <p> element. Is
the <p> element hidden? To authors this may very well ring true, but it
seems very unlikely that such a definition will ever reach
interoperability.


>> 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.
>
> Bullet 3 could be clearer.  We will rewrite it.

It still has the exact same issue.


>> 4. "Additional contribution of user-entered data" needs a much
>> more precise definition as well. "appended after" is also not
>> particularly clear here.
>
> The intent of rule 2B is to handle a specific case where a label on a
> widget contains an embedded control.  Furthermore, the embedded control  
> is multi-valent and set by the user (hence, "user-entered data").  An  
> example is a label on a checkbox where part of the label is a text field:
>
> [X] Flash the screen [input] times
>
> Here, "[input]" is a number entered by the user.  If the user has entered
> "5", the complete label is "Flash the screen 5 times".

But what would the widget be? Would be nice if the example was complete.


>> 6. 2D is also not very clear. What to do for SVG where tooltips
>> can contain markup?
>
> The text equivalent that is generated by this algorithm is plain text.
> Any markup would be filtered out.  For example, "<p>This is
> <em>excellent</em> chocolate cake</p>" gives the string, "This is  
> excellent
> chocolate cake".  This works like the innerText property in HTML.

That's a proprietary extension of some user agents. It's not part of any  
standard. In any case, assuming you mean something like textContent that  
would have to be defined because there are various ways you can get raw  
text out of markup.


>> 7. Point 3 is even less clear. List style bullets are not
>> generated text. Whitespace normalization needs to be defined
>> here.
>
> There is a note re: whitespace normalization following point 3.  Is that
> sufficient? We are rewording that note to read:
>
> Note: The purpose of the flat text equivalent string is to create
> something readable in alternative presentations. An implementation should
> insert whitespace characters when visually separate elements would be
> trimmed of white space and "jammed" together in the same string. For
> example, a space character may be inserted between the text of two
> paragraphs used one after the other in a description.

To be perfectly honest I find this whole section very hard to read and I  
have no idea whether I'm understanding it correctly. I very much doubt  
that the audience this is intended for (ordinary authors) will have a  
better experience.


> Comment 16: 4.3.1 Base Types
> --------------------------------
> Response from the Working Group:
> --------------------------------
> We have agreed that RFC 2119 statements do not belong in notes. We will
> reword appropriately to move RFC 2199 statements out of notes.

This does not appear to have happened everywhere, e.g. the note in  
http://www.w3.org/TR/2009/WD-wai-aria-20091215/roles#landmark still  
contains a MUST NOT.


> Comment 18: 5.2.4 Value
> --------------------------------
> Response from the Working Group:
> --------------------------------
> 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.

I strongly disagree with this. Having the values for ARIA attributes  
differ between markup languages would be very confusing. Please clearly  
define the allowed values and please consider aligning this with the  
definitions of HTML5 as it is most likely ARIA will be used most often in  
HTML.


> Comment 19: 6.1.1. Role attribute
> --------------------------------
> Response from the Working Group:
> --------------------------------
> 1. The issue of whitespace-separated string is addressed by relegating
> attribute processing rules to host languages, as explained in the  
> response to one of your earlier comments.

I think this is a very bad idea and disagree with this response.


> Comment 23: 7.2. All WAI-ARIA in DOM
> --------------------------------
> Response from the Working Group:
> --------------------------------
> We agree with your comments. The intent of this section is to ensure that
> DOM implementations expose all ARIA properties so that they may be  
> accessed
> by an assistive technology. We have clarified this in the spec.

I don't think the way this is worded is clear. Talking about properties in  
relation to the DOM without making it clear that these WAI-ARIA properties  
are actually content attributes is very confusing.


> Comment 24: 7.3. Web Application Notification of DOM Changes
> --------------------------------
> 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
> mentions to DOM mutation events. Satisfaction of this requirement may be
> achieved with DOM mutation event support, or with other future standards
> currently in discussion.

I still maintain my objection. The idea is that ARIA is driven by the  
author, not by anyone else. Others can tap into what is happening, but  
should not be able to modify. The whole notion of ARIA cannot be put up  
its head in such a small section. If the idea really is that plugins etc.  
can modify ARIA attributes and Web authors have to deal with that this  
should be made much more detailed.


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

Received on Friday, 19 February 2010 12:59:14 UTC