jupyter / accessibility

A repository for ongoing work around making Jupyter's software accessible and inclusive
https://jupyter-accessibility.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
66 stars 33 forks source link

Question about H1 on non-document, single-purpose pages #63

Closed minrk closed 2 years ago

minrk commented 2 years ago

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:

Screen Shot 2021-12-20 at 12 15 35

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):

Screen Shot 2021-12-20 at 12 16 49

And a third case, the admin page is one big table:

Screen Shot 2021-12-20 at 12 17 54

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:

A first level heading (<h1>) should be present on nearly all pages. It should contain the most important heading on the page (generally the document title).

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!

isabela-pf commented 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!

manfromjupyter commented 2 years ago

@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.

gabalafou commented 2 years ago

@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 page I 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 page This 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 page Again, 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.