Accessibility Audit

[walshbr]

While poking around with #1524 the tech team, we were discussing some contrast issues on the site. I ran Chrome's lighthouse on our site and found a number of accessibility issues. We'll need to poke around more closely to get a clear sense, so this is just a ticket to document the accessibility audit for the site. We should probably open separate tickets downstream for actually fixing particular issues.

[acrymble]

@walshbr I'm hoping we will have a UCL masters student in DH to help us think about this. Are you planning a particular type of audit? They'll be available in May.

[walshbr]

Cool! I just ran the site through Chrome's lighthouse feature, which is something anyone with Chrome can run from the developer tools menu. It gave these results -

So a mix of things that are clear, things that aren't, and things that need to be looked at by a human. I was just going to go through those myself, but if you have a student interested in this I'd be happy to let them do it or work with them on it.

[acrymble]

Only if the timeline works for you. I was also going to get them to think more holistically, about our workflows, messaging, etc. What you're doing is quite specifically technical.

[walshbr]

We can see where I'm at with the ticket when you bring someone on? If I had to guess, there will probably be a mix of things here, some more technical and some more monotonous. The former category is probably something the tech team should handle. But the latter category could be a good way for someone to learn about markdown, HTML, and GitHub in a light way. If that's something you want the student to work on though - totally your call. This definitely would be more technical, so fine to keep it with the tech team.

[acrymble]

You go ahead. We'll have the student support us from whatever point we're at in May.

[walshbr]

I'll collect the various elements we need to check and correct here as I go through them. And note that what I'm doing here is (in Chrome) opening developer tools, selecting lighthouse, and generating an accessibility report for each page. That's worth knowing because it tells you in that report how to correct a lot of these.

Pages I've checked so far (I think I got all the big buckets but if there's some other page I'm not thinking of let me know.

Home page layout:

• [role]s are not contained by their required parent element (some of the links in the top nav bar)
• Background and foreground colors do not have a sufficient contrast ratio. (link text in body and also the nav bar)
• main image does not have an alt attribute
• heading elements are not in a sequential order
• screenreader has issues with nav bar
• night mode

Additional things that need to be human checked:

• The page has a logical tab order
• Interactive controls are keyboard focusable
• Interactive elements indicate their purpose and state
• The user's focus is directed to new content added to the page
• User focus is not accidentally trapped in a region
• Custom controls have associated labels
• Custom controls have ARIA roles
• Visual order on the page follows DOM order
• Offscreen content is hidden from assistive technology
• HTML5 landmark elements are used to improve navigation

Contribute page overview

• Alt text

Contribute page feedback

• Alt text

Reviewer Guidelines

• Alt text

Author Guidelines

• Alt text

Translator Guidelines

• Alt text

Lesson Index

• Contrast

IPP Page

• Alt text
• Contrast

Individual Sponsor

• Background contrast
• alt text for image

Blog
Various things

General page layouts:
The above, but also…

• the header link (little chain link button to the right of subheaders) does not have a discernible name for screen readers)

Lessons page:
The above, but also…

• alt text for images is not being use for the gallery of lessons here (it's in the metadata, and we use it on the actual lesson page. but we need to add it here as well)
• images as links do not have discernible names (the lesson images themselves)

Lesson page:
The above, but also…

• heading elements are not in descending order - author name in metadata
• contrast (note that on the OCR and machine translation lesson the contrast audit failed for reasons I couldn't figure out)

About the team:
The above, but also…

• photos of team members need alt attributes
• contrast on this page

I'll discuss with the tech team how to divide these up. Should also note that these are all tests run against the desktop version of the site, but glancing quickly at the mobile output it appears that the issues are mostly the same. Also, for what it's worth, Lighthouse also has some useful performance audits that we could take a look at, but they probably aren't as pressing.

[acrymble]

@walshbr does this need £££?

[walshbr]

@acrymble I think if we wanted something much more thorough and comprehensive maybe? But I think the tech team can probably take care of this list if we're OK with just dealing with the lighthouse suggestions - none of these issues are too difficult…just a lot of small changes that we'll need to divide up so that they happen more quickly. I could take them all on myself but it would just take a while. I'm imagining it shouldn't be much more burdensome than the time that we went through and added alt attributes to all the lesson pages - not difficult but just a lot of small pieces. I think the tech team could probably handle it more quickly if we divide them up, but @ZoeLeBlanc could also comment if she has feelings.

Should also add that they might look like a lot, but I actually don't think this is that bad. I sort of expected it to be worse.

[walshbr]

Also note that most of the stuff flagged above is shared across pages, so if we address those all the pages will improve. But if there are large categories of pages or some that are more unique (like the about the team page) let me know - I can run the audit on those pages as well.

[ZoeLeBlanc]

Thanks for doing all of this @walshbr !!! This will be especially useful for the frontpage redesign #2020 .

Given the amount of things to do I'm wondering we want to schedule a call earlier than normal to break this up into discrete todos and discuss a game plan 🤔 ?

I feel like this would be a good time to both do some redesign work broadly, and also come up with a style guide documentation for the site overall. But also happy to chip away at these as we have time! Let me know if you and rest of @programminghistorian/technical-team have a preference!

[walshbr]

re: a broader redesign - we can talk about that if you want, but I'm not sure I have the capacity to do a whole lot of broad redesign work. And I'm not sure it's necessary wholesale? I'm just always skeptical of redesigns unless they're for a specific purpose. But we could certainly talk about it.

Regardless we definitely should not start work on this unless / until we know whether we would be doing so. Otherwise we'd be doing a lot of work that would get wiped away by a redesign.