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

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
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>

Received on Wednesday, 19 July 2017 19:50:03 UTC