- From: Rich Schwerdtfeger <richschwer@gmail.com>
- Date: Fri, 21 Jul 2017 07:35:30 -0400
- To: Joanmarie Diggs <jdiggs@igalia.com>
- Cc: Aaron Leventhal <aleventhal@google.com>, ARIA Working Group <public-aria@w3.org>
- Message-Id: <09B17D9D-7C6C-4EC9-9B80-CE9B2AF87BF0@gmail.com>
I have updated the core-aam to address values that are not allowed values for aria-current: https://github.com/w3c/aria/pull/610 Rich Schwerdtfeger > On Jul 20, 2017, at 7:54 AM, Joanmarie Diggs <jdiggs@igalia.com> wrote: > > I gave this a shot for the ARIA spec. Proposed changes: > * https://rawgit.com/w3c/aria/undefined/aria/aria.html (spec view) > * https://github.com/w3c/aria/pull/609 (pull request) > > Thoughts? > --joanie > > On 07/19/2017 09:37 PM, Aaron Leventhal 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 >> <mailto: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 <mailto: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. >>> 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> >>>>> <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 >>>>> >>>>> >>>>> >>>> >>> >
Received on Friday, 21 July 2017 11:35:57 UTC