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

Use <details> instead of roll-your-own content hiding #12212

Open
fluffy-critter opened this issue Oct 26, 2019 · 6 comments
Open

Use <details> instead of roll-your-own content hiding #12212

fluffy-critter opened this issue Oct 26, 2019 · 6 comments
Labels
suggestion Feature suggestion

Comments

@fluffy-critter
Copy link

fluffy-critter commented Oct 26, 2019

Pitch

Update the web UI HTML to use <details> instead of <button> for content warnings, to improve the markup semantics.

This is similar to #1464

Motivation

This would improve accessibility, particularly for users of screen readers.

@jalcine
Copy link

jalcine commented Oct 26, 2019

Even using a :focus approach could work here!

@ZoeBijl
Copy link

ZoeBijl commented Nov 1, 2019

Related to the :focus part: #12275

@nightpool
Copy link
Member

@fluffy-critter Can you (or someone else) update this issue with the actual, practical accessibility benefits using <details> would provide here? Just saying "This would improve accessibility" is not enough justification—what accessibility goals or success criteria are we attempting to fulfill, or currently don't meet? (aside from the Read More :focus issue, which is unrelated and should be tracked separately)

In particular, as far as trade-offs go, is it possible to keep details collapsed/expanded state in sync across multiple different DOM elements, the way our current content warnings work? (If a status's content warning is expanded, then it is expanded in all views a status can be shown in, and similarly when it is collapsed)

@nightpool
Copy link
Member

(The :focus issue is unrelated, it's an unintentional bug in the CSS code for statuses, caused by weird selector priority, and would still be the case using <details> or any other element)

@fluffy-critter
Copy link
Author

fluffy-critter commented Nov 1, 2019

Expanding/collapsing <details> elements can be accomplished by setting/clearing the .open attribute on them. See the snippets at https://stackoverflow.com/a/43009778/318857 for examples.

As far as the specific accessibility concern, using a semantic tag means that a screen reader has a better chance of understanding what the tag is and providing appropriate voice narration accordingly. It's good to be proactive about supporting these things so that the greater ecosystem gets a positive impact in the long term; breaking the chicken-and-egg accessibility cycle is important.

(Which is to say it isn't an urgent accessibility need at the moment, but it's the right thing to do.)

@bkil
Copy link

bkil commented May 1, 2023

Related: #17115

@vmstan vmstan added the suggestion Feature suggestion label Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion Feature suggestion
Projects
None yet
Development

No branches or pull requests

6 participants