Re: Ensuring "undefined" means undefined for aria-current

Joanie, that's great. I missed that.

Aaron

On Mon, Jul 24, 2017 at 2:31 PM Joanmarie Diggs <jdiggs@igalia.com> wrote:

> Hey Matt.
>
> I am in favor of aria-expanded being a supported property on menu items.
> However, I'm not convinced that's a non-normative change without the
> potential for unintended consequences. For instance, on my platform,
> native menu items are not expandable. Native menus.
>
> In contrast, I personally feel that the proposed change related to
> aria-current is stating what is essentially a tautology -- or should be:
> An "undefined" value is an undefined value.
>
> --joanie
>
> On 07/24/2017 07:38 PM, Matt King wrote:
> > Agree with the change.
> >
> > Who can make the call as to what is editorial? I agree this is an
> oversight and that implementing the spec as written today is not very
> developer friendly. But, if you read the text literally, which is normally
> the way we read specs, this is a change that impacts implementation.
> >
> > Perhaps the spec should stay as is and browsers should go ahead and
> implement aria-current the way we think it should have been written
> regardless of what the spec says.
> >
> > This is what has been done for aria-expanded on menuitems. Browsers have
> implemented support for it, and it works, but validators choke on it
> because the spec says it is not allowed.
> >
> > In other words, if this change to aria-current is editorial, then the
> change to allow aria-expanded on menuitems is editorial as well as it is a
> similar kind of oversight/error.
> >
> > Matt
> >
> > -----Original Message-----
> > From: Joanmarie Diggs [mailto:jdiggs@igalia.com]
> > Sent: Monday, July 24, 2017 9:20 AM
> > To: ARIA Working Group <public-aria@w3.org>
> > Subject: Ensuring "undefined" means undefined for aria-current
> >
> > Hey all.
> >
> > As I pointed out on the list [1], if aria-current is undefined because
> no value is specified, aria-current is false. But if aria-current is set to
> the value "undefined", aria-current is true. It was never (ever,
> > ever) intended for undefined and "undefined" to be opposite values. And
> normally they aren't. We just have an oddball case with aria-current
> because the spec states the following for aria-current:
> >
> > "Any value not included in the list of allowed values should be treated
> by assistive technologies as if the value true had been provided."
> >
> > It is my proposal that we fix this oversight by making the following
> change:
> >
> > Existing text: "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."
> >
> > Proposed text: "If the attribute is not present or its value is an empty
> string or <code>undefined</code>, the default value of false applies and
> the aria-current state MUST NOT be exposed by user agents or assistive
> technologies."
> >
> > I believe the above changes are editorial because surely no one thinks
> the string literal value "undefined" should mean the complete opposite of
> an undefined value. (Right? Right?? <smiles>)
> >
> > Feedback encouraged.
> > --joanie
> >
> > [1] https://lists.w3.org/Archives/Public/public-aria/2017Jun/0058.html
> >
> >
> >
>
>
>