Re: Okay - I admit it - I HATE Implicit Value for Role

> On Mar 26, 2015, at 8:13 PM, Shane McCarron <shane@aptest.com> wrote:
> 
> First - thanks for being so gracious in your replies.  After I sent that I sort of thought I was being an ass.
> 
> More comments inline
> 
> On Thu, Mar 26, 2015 at 9:29 PM, James Craig <jcraig@apple.com <mailto:jcraig@apple.com>> wrote:
> 
>> On Mar 26, 2015, at 4:21 PM, Shane McCarron <shane@aptest.com <mailto:shane@aptest.com>> wrote:
>> 
>> In ARIA 1.1 [1] there is a table row in some rows entitled "Implicit Value for Role".  
>> 
>> I have two problems with this.  
>> 
>> First, wow, that name is awful.  It implies (apologies for the pun) that it is about a value for role.  It is not.  
> 
> Agreed. Suggestions for a new name?
> 
> "Default State/Property Values" ?  "Default State and Property Values" ?  "Implied State and Property Values" ?  Something like that.

What about, "Default State and Property Values for Role"?

>> Second, when there is content (which is rare) it says things like "Default for aria-live is assertive."  That's probably correct, but I need more.  Why is this the case?  And does it convey this to subclasses of the role if there are any?  Enquiring minds want to know.
> 
> I can probably give an example for each if we have a consistent place to mention it. Suggestions? In addition to he table row, I think there is a note in each role section. We could add the explanation there.
> 
> I like the idea (in general) of explaining anything that is unusual for any role. Each role that introduces a new state / property should explain why.  It is probably obvious to whomever wrote it in the first place, but outside of that room.... some of it is not.  
> 
> Examples might be overkill.  Just a little prose that says "property X is relevant to role Y because, in the expected use model Z it is important that we have a well known range of values" or whatever.  It's not a normative requirement.  It's just text that helps the reader with context about the role, it's position in the taxonomy, and the various states / properties that it inherited or introduced.
> 
> I can probably provide some example text, but first I would like to know if anyone else would find this valuable.  Otherwise I won't push on this rope too hard.

I would. The note seems like a logical place. For example:

For alert, change:
NOTE
Elements with the role alert <http://rawgit.com/w3c/aria/master/aria/aria.html#alert> have an implicit aria-live <http://rawgit.com/w3c/aria/master/aria/aria.html#aria-live> value of assertive, and an implicit aria-atomic <http://rawgit.com/w3c/aria/master/aria/aria.html#aria-atomic> value of true.

To:
NOTE
Elements with the role alert <http://rawgit.com/w3c/aria/master/aria/aria.html#alert> have a default aria-live <http://rawgit.com/w3c/aria/master/aria/aria.html#aria-live> value of assertive, and a default aria-atomic <http://rawgit.com/w3c/aria/master/aria/aria.html#aria-atomic> value of true. Alerts represent critical information to the user, so these defaults allow users to perceive changes to the alerts immediately.


And for checkbox, add:
NOTE
Elements with the role checkbox have a default aria-checked value of true. Assistive technologies will assume checkboxes are "unchecked" even if the author have not explicitly added the attribute: aria-checked="false".

etc. etc.

>> Sorry if this sounds like I am trivializing this.  I don't mean to.  This category of information about roles is confusing.  And I don't feel like this is an area where we really want confusion.
>> 
>> 
>> [1] http://w3c.github.io/aria/aria/aria.html <http://w3c.github.io/aria/aria/aria.html>
>> 
>> -- 
>> Shane McCarron
>> Managing Director, Applied Testing and Technology, Inc.
> 
> 
> 
> 
> -- 
> Shane McCarron
> Managing Director, Applied Testing and Technology, Inc.