Re: Seeking clarification for "undefined" as a literal value

Hi Aaron, 

In the case of aria-current the default value is false - even when the attribute is not set. I am looking at the list of values for aria-current and “undefined” is not in the list. It does not take a value of “undefined. So, if a value of “undefined” is provided (which is an invalid value as it is not in the list) it should be set to “true” and passed to the assistive technology with a value of “true". See Joanie’s note and the aria-current spec. 

http://rawgit.com/w3c/aria/master/aria/aria.html#aria-current

My previous response to you was regarding aria-checked and not aria-current. 

What is important is that the AT is aware of a set of known values of which “undefined” is not in the list of values for aria-current. The reason for exposing the value of “true” to ATs was that the author made an effort to set the value to something but it is not a value that the AT would understand. 

Looking at the Core-AAM I can see where the confusion is. Perhaps what the core-aam needs to say is: 


<change> 
aria-current is undefined [ARIA 1.1]
MSAA + IAccessible2  Not mapped* <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
UIA Not mapped* <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
ATK/AT-SPI Not mapped* <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
AX API Not mapped* <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
</change>
<to>

aria-current is not present or “”:
aria-current is undefined [ARIA 1.1]
MSAA + IAccessible2  Not mapped* <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
UIA Not mapped* <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
ATK/AT-SPI Not mapped* <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
AX API Not mapped* <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
aria-current not “” and is not in the list of defined values:


</to>

MSAA + IAccessible2  
Expose the value of aria-current in object attribute current:true.
UIA Expose current=“true" in AriaProperties.
ATK/AT-SPI 
Set STATE_ACTIVE.
Expose the value of aria-current in object attribute current:"true".
AX API AXARIACurrent: true.


</to>

Is that clear enough or should I change the wording?

Sorry for my slow response. We lost power due to tropical wave “Don”.

Rich


Rich Schwerdtfeger




> On Jun 30, 2017, at 10:13 AM, Aaron Leventhal <aleventhal@google.com> wrote:
> 
> To be clear, I've never seen the "undefined" literal used in the real world, but it's good to get this right anyway.
> Are these correct:
> 
> - The author can explicitly set the "undefined" literal unless the property is required for the role.
> 
> - Setting "undefined" is equivalent to using the default value
> 
> - The default value itself may be "undefined" (like in aria-checked) or not (e.g. "false" for aria-disabled). Therefore, using "undefined"/undefined may result in undefined or a specific value depending on the property.
> 
> IMO the CORE-AAM could use more clarification. I don't find it covers these cases -- at least it's not clear to me.
> 
> Aaron
> 
> 
> 
> 
> On Fri, Jun 30, 2017 at 9:09 AM Joanmarie Diggs <jdiggs@igalia.com <mailto:jdiggs@igalia.com>> wrote:
> This does have interesting implications for (at least) aria-current.
> According to the ARIA spec:
> 
>     The aria-current attribute is an enumerated type. Any value not
>     included in the list of allowed values should be treated by
>     assistive technologies as if the value true had been provided. If
>     the attribute is not present or its value is an empty string, the
>     default value of false applies and the aria-current state must not
>     be exposed by user agents or assistive technologies.
> 
> Thus the language is consistent with what Rich said, which means: If the
> value of aria-current is undefined (in the sense of a value having not
> been provided), the default of false applies, the element is not
> current, and the aria-current state must not be exposed. BUT, if the
> value of aria-current is "undefined" (a string literal), then we have a
> value not included in the list of allowed values, which should be
> treated as if aria-current were set to true (which means the
> aria-current state must be exposed by user agents).
> 
> The fact that the results of undefined and "undefined" are expected to
> be the complete opposite gives me a headache.
> 
> Also, looking at the Core AAM, aria-current is undefined is "not
> mapped":
> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaCurrentUndefined <https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaCurrentUndefined>.
> I guess Joseph thinks undefined means not defined? (To be honest, that's
> how my brain works too.) And I guess we need to add both flavors of
> undefined to Core AAM?
> 
> --joanie
> 
> On 06/29/2017 01:47 PM, Rich Schwerdtfeger wrote:
> > Aaron,
> >
> > The spec. clearly states that (see aria-checked) that “undefined” is the
> > (default). If nothing is specified that is what is assumed the value is.
> > If the author has not set aria-checked on the role that supports the
> > aria-checked states then the default is undefined. When it says default
> > it is very clear. Had default not been indicated then I agree there
> > would be confusion.
> >
> > So, “undefined” is a valid value. … so is leaving the attribute off
> > altogether.
> >
> > In aria 1.0 here is a test example for aria-grabbed being set to
> > “undefined” from the Candidate Recommendation test harness:
> >
> > https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA/1.0/tests/test-files/roles-properties-global/roles-properties-global-main-aria-grabbed-undefined.html <https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA/1.0/tests/test-files/roles-properties-global/roles-properties-global-main-aria-grabbed-undefined.html>
> >
> > This passed candidate recommendation and therefor we had working
> > implementations.
> >
> > The important thing to remember is the default value. So, programmers
> > can leave it off altogether.
> >
> > Rich
> >
> >
> > Rich Schwerdtfeger
> >
> >
> >
> >
> >> On Jun 29, 2017, at 1:32 PM, Aaron Leventhal <aleventhal@google.com <mailto:aleventhal@google.com>
> >> <mailto:aleventhal@google.com <mailto:aleventhal@google.com>>> wrote:
> >>
> >> As I understand ARIA, a possible value of "undefined" means the
> >> attribute is not present. If undefined is also the default, then a
> >> value of "" is equivalent. However, I would not expect a user agent to
> >> process the literal string "undefined" as undefined.
> >>
> >> Was there an expectation somewhere that the literal string "undefined"
> >> should be treated as attribute not present?
> >>
> >> I feel that the ARIA 1.1 spec could be more clear here:
> >>
> >> 'The "undefined" value, when allowed on a state or property, is an
> >> explicit indication that the state or property is not set. The value
> >> is used on states and properties that support tokens, and the
> >> "undefined" value is a string that is one of the allowed tokens. It is
> >> also used on some states and properties that accept true/false values,
> >> when "undefined" has a different meaning than "false".'
> >>
> >> Perhaps when undefined is discussed it should not be put in quotes --
> >> to programmers this means literal string. Mostly, CORE-AAM does this,
> >> but it does have one place under disallowed values that discusses
> >> "undefined" as a literal string. It does not, however, discuss the
> >> "undefined" literal as an allowed value.
> >>
> >> Can someone provide more clarity for our implementation? I'd like to
> >> see more clarity in both specs.
> >>
> >> Thank you,
> >>
> >> - Aaron
> >>
> >>
> >>
> >
>