Closed minrk closed 2 years ago
It's not the wrong place at all! I need to give this a good read and haven't had a chance yet, but thank you for opening this issue. It's on my radar!
@minrk It is typically a good practice to always expose your H1, but in some instances you want to hide it for design reasons or change where you want it to appear due to it being in an unconventional place for screenreaders. It is an accessibility requirement to have an H1 on every page IF any other headings appear and is a good practice even if there isn't because it provides additional landmarks for screenreaders. This is required to appear first in the <body>
when used in conjunction with other headings, but some elect to have the <h1>
hidden with sr-only
and place where it makes sense for the screenreader (at the top of the <body>
). Then for visual users, designers with accessibility in mind may either not have it appear at all or have it appear as just a <p>
element that is hidden to screenreaders with aria-hidden="true"
for example just styled to look like a real H1.
Best example I can think of
<body>
<header>...</header>
<main>
<h1 class="sr-only">Dashboard</h1>
<div class="sidebar" role="complementary">
<h2>Actions</h2>
<button>...</button>
<button>...</button>
<button>...</button>
</div>
<section>
<p class="fake-h1">Dashboard</p>
<!-- Insert graphs here -->
</section>
</main>
<footer>...</footer>
</body>
Inside mind of Designer - Designer wants to make these headers in line with another, but they want to make the section to the right slightly bigger than the sidebar area to the left. The section with the fake H1 is desired to be the focus which is why they want it bigger. If the user moved the real H1 there, it would be a landmark (headings-order) violation because it would appear after the H2 in the DOM order.
fake-h1
be a H2 and change the name of the H1 to "Dashboard page" or something. This would also be allowed too.<section>
. They obviously could and it would be allowed, but maybe this dashboard section is HUGE and they don't want ambulatory users to have to tab through 200 elements to get to a ex. "Export Dashboard" button found in the sidebar. By having the sidebar area first because it's small and a heavily traveled region, they might prefer not moving the sidebar for the sake of an easy UX.@manfromjupyter, thanks for your response. I learned some good things from it! Especially the part about how headings need to be in the right order in the DOM tree (h1 before h2 before h3 etc.)
I have a few thoughts about the JupyterHub pages that I would like to add. I still have a lot to learn about web accessibility, I have been working in this space for only three months, so please take what I write below with a grain of salt.
I will respond to each of @minrk's earlier examples, one by one.
I think it's super awesome that you're thinking about this stuff and asking these questions. Please don't hesitate to reach out if you have any questions. I'm on Gitter.
EDIT: I realized after I posted this that the username "admin" cannot be clicked in the navigation bar, which invalidates a point I made in Example 3.
Thanks for the wonderful accessibility workshop last week!
I've been playing with WAVE on JupyterHub pages, and trying to find some low hanging fruit, and there definitely are some. I've hit a few I don't quite know what to do with, though.
The first is that several JupyterHub pages don't have an
h1
because there is no heading. Most JupyterHub pages are single-purpose, where a text heading is redundant with the HTML title, url, etc., and in some cases would be most of the content of the page.For instance, the login page looks like this:
Should I make that
Sign In
an H1?Similarly, the 'home page' is really one button to get to your server (or two, if you want to stop it):
And a third case, the admin page is one big table:
Is it considered best practice to duplicate the HTML title into page content for every page of an application? That doesn't feel right, but I'm sure there are accessibility issues I'm not aware of. I don't feel like I have the information available to make "this guideline does not apply in this context" decisions.
In general, the WCAG text that comes up:
seems to assume that web pages are documents and not applications.
When I check for another example of what I hope is a good page, the GitHub dashboard, which also doesn't have a logical heading in the default view, has a hidden
<h1 class="sr-only">Dashboard</h1>
. Is this a good pattern to follow to add hidden structural content for readers-only?Sorry if this is the wrong place to ask questions like this, I'm just excited to be able to make progress!