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

Rich, one more note. I do think that the ARIA spec does have a possible
conflict as the following general text is provided that conflicts with what
aria-current says about an unknown value being equivalent to true:
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".

I would think the above general text can be thought of as applying to
aria-current, otherwise it's a bit weird. Unless you tell me otherwise, I
will implement aria-current="undefined" as false, which is really what
would make the most sense for authors and users.

Aaron



On Wed, Jul 19, 2017 at 3:49 PM Aaron Leventhal <aleventhal@google.com>
wrote:

> Yes, thank you, I would really appreciate seeing the specs aligned.
>
> Do you agree that "undefined" and undefined are different for
> aria-current? Are there any other properties that do that?
>
> Aaron
>
> On Wed, Jul 19, 2017 at 3:41 PM Rich Schwerdtfeger <richschwer@gmail.com>
> wrote:
>
>> Hi Aaron,
>>
>> I think it always good to do that. Technically, there is nothing wrong
>> with ARIA 1.1 but I do see where there can be confusion on the use of
>> undefined values - although the ARIA spec. is clear. I would recommend that
>> this be done for ARIA 1.2 given our tight schedule.
>>
>> That said, would you like us to make the changes, I suggested, to the
>> core-aam so that is aligned with the spec.?
>>
>> At least you will know exactly what should be implemented from a user
>> agent perspective.
>>
>> Rich
>>
>> Rich Schwerdtfeger
>>
>>
>>
>>
>> On Jul 19, 2017, at 3:37 PM, Aaron Leventhal <aleventhal@google.com>
>> wrote:
>>
>> Thank Rich, I agree with Joanie that it's weird when "undefined" and
>> undefined (not present) mean different things, as it does in this case.
>> That one might be so counterintuitive that most implementors would get it
>> wrong. Most of us are not like Data on Star Trek.
>>
>> I also don't think it would be a bad idea to sweep through the various
>> specs at some point and help clarify wording via non-normative changes.
>>
>> Aaron
>>
>>
>> On Wed, Jul 19, 2017 at 2:30 PM Rich Schwerdtfeger <richschwer@gmail.com>
>> wrote:
>>
>>> 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>
>>> 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
>>>> .
>>>> 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
>>>> >
>>>> > 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>> 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
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>