Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an example disclosure widget without the definition list #830

Open
DavidMacDonald opened this issue Aug 13, 2018 · 1 comment
Open
Labels
enhancement Any addition or improvement that doesn't fix a code bug or prose inaccuracy Feedback Issue raised by or for collecting input from people outside APG task force

Comments

@DavidMacDonald
Copy link

DavidMacDonald commented Aug 13, 2018

There are times when a definition list may not be the best semantics. Consider a simple example with a

<button aria-expanded="false">[Trigger title]</button>
<p style="display:none;">Content</p>

Is aria-controls really necessary when the content immediately follows the trigger? It causes additional complexity and burden on the author of choosing unique ids ...

The other example I see a lot of in the wild is for a heading to be expandable.

<h3><button aria-expanded="false">[Trigger title]</button></h3>
<p style="display:none;">Content</p>
@mcking65 mcking65 added enhancement Any addition or improvement that doesn't fix a code bug or prose inaccuracy Feedback Issue raised by or for collecting input from people outside APG task force labels Aug 15, 2018
@mcking65
Copy link
Contributor

@DavidMacDonald,

Is there anything about the example page that implies you can't simply remove the dl and have asingle, free-standing button? I'd be happy to modify the description or accessibility notes if there is anything that implies the dl is essential.

I think we cover the collapsable heading approach in the accordion pattern, which I should list in similar examples. BTW, the accordion is going to be re-built without dl (see #815).

About aria-controls ... It's purpose, effects, and requirements are being discussed in a variety of places, e.g., w3c/aria#531. The disclosure will certainly work for screen reader users without aria-controls. However, I think we will wait until we have more clarity at the spec level before deciding whether or not to change anything in the examples that use it.

Personally, I see 1 existing benefit and several potential benefits to using aria-controls. Today, it can be helpful to automated testing, such as the regression testing we are implementing for the APG. I would also love to have simple and user friendly exploitation of it by screen readers. For instance, when reading the expanded content, I'd love to be able to easily jump the reading cursor back to the controlling button from any point in the controlled container with a general purpose undo/go-back type of quick key. I definitely would not want a key dedicated to that purpose, however. My brain already has too many thousands of key commands taking up space that would be better used for other things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Any addition or improvement that doesn't fix a code bug or prose inaccuracy Feedback Issue raised by or for collecting input from people outside APG task force
Development

No branches or pull requests

2 participants