Correction: conditionally revise allowed attributes and roles on summary element

[scottaohara]

Normative follow-on from #434

The spec was updated to note that the summary element doesnt' always map to the button element. The allowed attributes indicated that all attributes that were applicable to the button role were allowed. However, in practice this doesn't make sense and could break or be in contradiction to the implicit semantics.

The allowed aria-* attributes for the button role include

• aria-disabled
• aria-haspopup
• aria-expanded
• aria-pressed

Edit: after testing, aria-expanded and aria-pressed provide zero value on a summary element, as they are presently ignored by user agents (browsers/AT). https://codepen.io/scottohara/pen/ZEjZPoR

markup and results of linked codepen

<details open>
    <summary aria-pressed=false>test 1</summary>
    aria-pressed on summary element
</details>

<details open>
    <summary aria-expanded=false>test 2</summary>
    aria-expanded=false on summary element
</details>

<details open>
    <summary aria-haspopup=dialog>test 3</summary>
    aria-haspopup=dialog on summary element
</details>

<details open>
    <summary aria-disabled=true>test 4</summary>
    aria-disabled=true on summary element
</details>

test 1
JAWS/NVDA+Chromium/Gecko - attribute ignored
Narrator+Edge - attribute ignored / UIA ignores attr
iOS/macos safari/firefox+VO - ignored

test 2
JAWS/NVDA+Chromium/Gecko - attribute ignored
Narrator+Edge - attribute ignored / UIA ignores attr
iOS/macos safari/firefox+VO - ignored

test 3
JAWS/NVDA+Chromium/Gecko - announces as a button menu
Narrator+Edge - has popup
macOS VO + Safari - has popup
iOS VO + safari, macOS VO firefox - ignored

test 4
JAWS/NVDA+Chromium/Gecko - disabled state conveyed
Narrator+Edge - disabled
iOS/macOS Safari/firefox+VO - disabled

Concerning the allowed roles for a summary element. A summary element can be one of two things, the 'summary for its parent details' - where it acts as the triggering element for the disclosure widget. Or, if it doesn't meet the conditions to be that (e.g., it is not a child of a details element, or it is not the first instance of a summary element - e.g., it's the 2+ summary element within a details), then it is treated as a generic element, so any role/attribute should be allowed.

test cases - https://w3c.github.io/html-aria/tests/summary-allowances.html

• [ ] HTML Validator
• [x] IBM equal access accessibility checker
• [ ] axe-core
• [x] ARC toolkit

(linked issues to each checker referenced in the following thread)

---

Preview | Diff

[JAWS-test]

What is the use case for aria-haspopup?

[scottaohara]

I need examples of why people shouldn't be able to use this and what accessibility issues it would create if they did use this.

I have my own opinions on the matter, but my opinions dont' really count so long as it could be used in a way that there was no accessibility issues caused if used appropriately. without evidence that shows it's a problem, I'm wary to remove the allowance since up until this lands, it would have been "supported"

[JAWS-test]

I can't imagine how summary, which shows and hides areas, would have a popup at the same time. How is the popup opened? I also think that hardly anyone uses aria-haspopup on summary yet - maybe a scan of the web can shed some light on this

[scottaohara]

@JAWS-test you can take a look at this web page and you'll find instances of people using role=button aria-haspopup on summary elements.

here's a very quick test i made to demonstrate / verify the behaviors in safari, chrome and firefox on macOS: https://codepen.io/scottohara/pen/bGKpOJP

firefox + vo don't say boo about the aria-haspopup. oh well.
safari + chrome + vo convert the summary to a role=button automatically with the use of aria-haspopup, and the trigger announces 'pop up dialog' as the signal of what it'll open.

i have not tested on windows yet, but i do not anticipate variations too far off from the above.

again, putting aside my own thoughts on whether someone could/should do this or not, or if the attribute makes sense on the element in other contexts, if the spec were to not allow the aria-haspopup attribute on the summary element, then that example would be flagged as invalid because.......

Because why?

If i can't answer that question, I can't justify removing it.
(note: i've tasked myself to ask that question about many rules outlined in this spec. I merely mention that not to start talking about that here, but to indicate it's something that is on our minds and there will be future updates to address any instances of where 'why' cannot be answered).

[JAWS-test]

Because why?

Because a button that hides and shows an area cannot have a second function at the same time, which is to open a popup.

[JAWS-test]

Because why?

Because buttons with aria-haspopup are often output as menu buttons, which is 1. wrong and 2. leads to the fact that the actual status of the button (area open or closed) is not perceptible. E.g. with JAWS + Chrome.

[scottaohara]

Because why?

Because a button that hides and shows an area cannot have a second function at the same time, which is to open a popup.

well this response doesn't take into account the test case i provided DOESNT do this. It hides/shows a dialog popup and nothing else. it works exactly as it's supposed to. So, again. Why? Your answer isn't sufficient for the use case provided. Why make it completely invalid if there are valid use cases? Seems quite outside the scope of what should be specified here.

But let's move onto the next response why, as it actually has more merit but still falls short:

Because buttons with aria-haspopup are often output as menu buttons, which is 1. wrong and 2. leads to the fact that the actual status of the button (area open or closed) is not perceptible. E.g. with JAWS + Chrome.

Well for screen reader browser pairings which use the IA2 mappings... sure. But by this logic then aria-haspopup shouldn't be allowed on buttons at all. Or at the very least one could infer that any value other than menu or true should make the attribute not allowed on buttons. But that seems silly. To say an attribute isn't allowed due to the fact there are implementation issues with browser mappings. Seems more like effort to get https://github.com/w3c/core-aam/pull/86 should be the concern.

[JAWS-test]

@scottaohara I mistakenly assumed that aria-expanded and aria-haspopup referred to different content being displayed. If it refers to the same content, then using aria-expanded and aria-haspopup at the same time could be correct. To that extent, I withdraw my objection. Sorry for the trouble