Replies: 3 comments
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
@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 Best example I can think of 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.
|
Beta Was this translation helpful? Give feedback.
-
|
@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. Example 1: JupyterHub sign in pageI think it makes sense to make "Sign In" an h1. That way, someone using a screen reader would be able to hit a keyboard shortcut and go directly to "Sign In" and have it read. This could act as a kind of re-assurance that, yes, they are on the sign in page. Example 2: JupyterHub home pageThis is just my opinion but I do not think it would hurt the UI to add an h1 to this page that says "Home" or "Home Page." The main reason I say this is that the navigation bar doesn't have any visual indicator to let the user know which page they are on. So an h1 would fill that gap. Example 3: JupyterHub admin pageAgain, just my opinion, but for the same reason that I gave for the home page, I think it wouldn't hurt the admin page to have an h1 that says "Admin." Furthermore, there is a bit of ambiguity when you are logged on as user "admin." If the admin page has an h1 that says "Admin Control Panel" whereas the user page for the user "admin" has an h1 that says "My Account Settings" or something like that, then that helps to disambiguate the user interface. 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. |
Beta Was this translation helpful? Give feedback.
-
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
h1because 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 Inan 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!
Beta Was this translation helpful? Give feedback.
All reactions