- From: Aaron Leventhal <aleventhal@google.com>
- Date: Wed, 19 Jul 2017 19:49:30 +0000
- To: Rich Schwerdtfeger <richschwer@gmail.com>
- Cc: Joanmarie Diggs <jdiggs@igalia.com>, ARIA Working Group <public-aria@w3.org>
- Message-ID: <CA+1LECQCKE6+cOAFoXMAcj81L6D2E8ocGxWWmY=eUXVH2xocDw@mail.gmail.com>
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