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

In CORE-AAM, the "undefined" literal string is only mentioned in this
section, which only discusses unknown or disallowed values, whereas
"undefined" can be an allowed value. Further, "undefined" as a literal
string is only addressed in a sub section of that about boolean states, yet
"undefined" can be used on non-boolean properties.

If a WAI-ARIA property contains an unknown or disallowed value, the user
agent should expose to platform accessibility APIs
<http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#dfn-accessibility-api>
 as follows:

   - When exposing as an object attribute, expose the unknown value — do
   not vet it against possible values.
   - When exposing as a platform API Boolean state
   <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#dfn-state>:
      - For values of "" (empty string), "undefined" or no attribute
      <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#dfn-attribute>
       present:
         - Follow the guidance in the Default values for missing required
         attributes
         <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#authorErrorDefaultValuesTable>
          table below, if applicable.
         - Otherwise, treat as false.
      - Treat any other value as true.
   - Otherwise, ignore the value and treat the property as not present.


On Fri, Jun 30, 2017 at 12:04 PM Rich Schwerdtfeger <richschwer@gmail.com>
wrote:

> Yes. The reason for undefined was that we could not assume that something
> was false by default - especially when in the case of a checkbox it could
> be “mixed”.
>
> If a property is required for a role it could be undefined. … You might be
> waiting for a server to tell you what the value is such as for preferences
> for a given user.
>
> I am a little confused about where you think the core-aam is unclear.
>
> Here is the current core-aam. The spec. clear states what the default
> values must be for states and properties and we have mappings associated
> with each value (which indicates the default):
>
> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html
>
> see aria-disabled. It indicates the default. The core-aam reflects the
> spec.
>
>
>
> 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
>> >>
>> >>
>> >>
>> >
>>
>>
>