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

CSS+JS Accessibility best practices - hidden things section - is not promoting best practices #37524

Open
scottaohara opened this issue Jan 6, 2025 · 4 comments
Labels
Content:Learn:Accessibility Accessibility documentation in the Learn Area goal: best practices (Experimental label) Issues about content displaying unusual approaches.

Comments

@scottaohara
Copy link
Contributor

MDN URL

https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Accessibility/CSS_and_JavaScript

What specific section or headline is this issue about?

Hiding things

What information was incorrect, unhelpful, or incomplete?

the hiding things tab widget demo description doesn't match the demo / is inaccurate.

What did you expect to see?

the demo needlessly uses position absolute (as the linked demo is using display none to hide the inactive tab panels - so position absolute is useless here)

the end of the first paragraph states: "you can alternatively use Tab and Enter/Return to select them)."
but the demo allows initial tab key press to go to the first tab, but then uses arrows to navigate between the tab items. This sentence should mention the use of left/right arrow keys

Screen reader users don't care about any of this — they are happy with the content as long as the source order makes sense, and they can get to it all. Absolute positioning (as used in this example) is generally seen as one of the best mechanisms of hiding content for visual effect because it doesn't stop screen readers from getting to it.

this section should just be removed. i'm not going to get into how inaccurate this is / how it's not a good practice to use absolute positioning this way - but since the demo doesn't even need the absolute positioning, it'd be best to remove this all together.

On the other hand, you shouldn't use visibility: hidden or display: none, because they do hide content from screen readers. Unless of course, there is a good reason why you want this content to be hidden from screen readers.

the demo DOES use display none though - which is what this should be doing. so this paragraph is both inaccurate to the demo, and not the best advice in general for building a tab widget.

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

i came across this demo when poking through this PR and noticing the version of the tab demo there was built in a way that wasn't really something we should want devs to copy.

following back to this article, i noticed that the demo here was built better, but the text of this page seemed to be written as if it expected the demo in the linked PR to have been used.

these demos should match, and the information surrounding them needs to be consistent / not promoting bad or unnecessary CSS / ARIA practices.

MDN metadata

Page report details
@github-actions github-actions bot added needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. Content:CSS Cascading Style Sheets docs labels Jan 6, 2025
@bsmth
Copy link
Member

bsmth commented Jan 8, 2025

Scott, thank you for taking the time to write up the issue, it's much appreciated. Should we first move the code inline into the page, then follow up with an improvement PR that addresses the problems?

One of the benefits of inlining the examples in content like that is we surface these kinds of problems. Currently, the included/embedded code is completely opaque in mdn/content, so it's difficult to spot patterns like this.

@scottaohara
Copy link
Contributor Author

scottaohara commented Jan 8, 2025

The content is the major issue here. The demo by comparison is doing a better job

Inlining the demo seems like a task that could be done when fixing this, but it isn’t as important as fixing the inaccurate content

@bsmth
Copy link
Member

bsmth commented Jan 8, 2025

OK, let's consider the PR incomplete until the changes there address the inaccurate content, in that case, how does that sound?

@scottaohara
Copy link
Contributor Author

scottaohara commented Jan 8, 2025

yeah, just inlining the demo would completely miss the point of the issue :D so if that happens at the same time as fixing this content, neat.

but i really can't care less about the demo being in lined or not (i realize there's an effort to do that. but it's just not my concern with this issue).

tbh, i'm actually a little nervous about the other issue/pr and in lining aria-live demos (unless a button is added to only initiate the demo when a user explicitly wants to check it out - maybe that's the case for how those will work?). i don't think the live region demos work right now, from looking at the preview - but if a page starts automatically announcing aria-live demos without context, that'd be rather frustrating.

@Josh-Cena Josh-Cena added Content:Learn:Accessibility Accessibility documentation in the Learn Area and removed Content:CSS Cascading Style Sheets docs needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. labels Jan 8, 2025
@caugner caugner added the goal: best practices (Experimental label) Issues about content displaying unusual approaches. label Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content:Learn:Accessibility Accessibility documentation in the Learn Area goal: best practices (Experimental label) Issues about content displaying unusual approaches.
Projects
None yet
Development

No branches or pull requests

4 participants