sort of strange but that we do that for many things, here we are inconsistent. ARIA 1.0 464 failure (https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA/1.0/tests/test-files/roles-properties-required/roles-properties-required-checkbox-aria-checked-undefined.html)

correct patch

(In reply to alexander :surkov from comment #0) > sort of strange but that we do that for many things, here we are > inconsistent. so <div aria-checked="undefined"> and <div aria-checked=""> might as well be

err, might as well be <div aria-checked="false">? that seems kind of broken or atleast silly.

I'm not sure I understood question

if I understand the code correctly writing any of the following does the same thing <div aria-checked=""> <div aria-checked="false"> <div aria-checked="undefined"> I claim if I'm reading it correctly then what we do is kind of broken or atleast very silly.

if all divs have role="checkbox" then that's right. they are all equivalent. the problem is omitted attribute and "undefined"/etc value are the same per spec but role="checkbox" is checkable by default so absent/undefined values keep it as checkable. I hope they will address it in ARIA 1.1

(In reply to alexander :surkov from comment #7) > if all divs have role="checkbox" then that's right. they are all equivalent. > the problem is omitted attribute and "undefined"/etc value are the same per > spec but role="checkbox" is checkable by default so absent/undefined values > keep it as checkable. I hope they will address it in ARIA 1.1 so, how do you think it *should* work?

I'd be happy if undefined was a special value meaning that the property is not applicable to the role. Next absent, "" values are equivalent to "false" value for roles that the property is an essential feature for (like aria-checked for checkbox since checkboxes are usually checkable) and equivalent to "undefined" in other cases (like aria-selected for columnheader since column header is often not selectable). But I don't care so much to have a fight for this.

(In reply to alexander :surkov from comment #9) > I'd be happy if undefined was a special value meaning that the property is > not applicable to the role. Next absent, "" values are equivalent to "false" > value for roles that the property is an essential feature for (like > aria-checked for checkbox since checkboxes are usually checkable) and wouldn't defaulting to true be more similar to thinks like disabled and checked attributes? > equivalent to "undefined" in other cases (like aria-selected for > columnheader since column header is often not selectable). always defaulting to true feels a little more natural and would be simpler. > But I don't care so much to have a fight for this. the way attributes work in html is so bad I'm not sure I care much either.

(In reply to Trevor Saunders (:tbsaunde) from comment #10) > (In reply to alexander :surkov from comment #9) > > I'd be happy if undefined was a special value meaning that the property is > > not applicable to the role. Next absent, "" values are equivalent to "false" > > value for roles that the property is an essential feature for (like > > aria-checked for checkbox since checkboxes are usually checkable) and > > wouldn't defaulting to true be more similar to thinks like disabled and > checked attributes? basically they do defaulting to true, i.e. any unrecognized value is mapped to true > > equivalent to "undefined" in other cases (like aria-selected for > > columnheader since column header is often not selectable). > > always defaulting to true feels a little more natural and would be simpler. I think they wanted to have an option to "remove some property" like make checkbox uncheckable, not sure it's really useful though but it seems it's gone now and "undefined" is just rudiment. > > But I don't care so much to have a fight for this. > > the way attributes work in html is so bad I'm not sure I care much either. ok, what about patch?

Comment on attachment 776654 [details] [diff] [review] patch2 I wish aria bool attributes just worked like html ones but ok :/