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:

• [x] [role]s are not contained by their required parent element (some of the links in the top nav bar)
• [x] Background and foreground colors do not have a sufficient contrast ratio. (link text in body and also the nav bar)
• [x] main image does not have an alt attribute
• [x] 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

• [x] Alt text

Contribute page feedback

• [x] Alt text

Reviewer Guidelines

• [x] Alt text

Author Guidelines

• [x] Alt text

Translator Guidelines

• [x] Alt text

Lesson Index

• [x] Contrast

IPP Page

• [x] Alt text
• [x] Contrast

Individual Sponsor

• [x] Background contrast
• [x] alt text for image

Blog Various things

General page layouts: The above, but also…

• [x] 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…

• [x] 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)
• [x] images as links do not have discernible names (the lesson images themselves)

Lesson page: The above, but also…

• [x] heading elements are not in descending order - author name in metadata
• [x] 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…

• [x] photos of team members need alt attributes
• [x] 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.

[ZoeLeBlanc]

Mostly the redesign I had in mind was for the front page and then standardizing what we already have across the site. Adding the color variables has started to help doing that but right now it feels pretty ad hoc, so just wondering if we could produce more of a style guide that would allow us to have some coherency (but that might just be a perfectionist tendency getting in the way of good enough!)

[walshbr]

Yeah that could be good! I like that idea.

[acrymble]

@walshbr happily, I've got some funding from UCL's Faculty of Arts & Humanities to support some of this work. They've agreed to pay Dr Amy Kavanagh (https://amykavanagh.co.uk/) who is both a historian and a disability rights activist, to take a look at the wider project and make recommendations on supporting visually impaired users in particular. She's going to try to send us a report in the next few weeks, which may highlight some other areas beyond the technical for us to think about. I'll let you know how that goes.

[walshbr]

That sounds good!

[walshbr]

I've been chipping away at these - the plan is for me to do as many of the general checks as I can, and then I'll talk with the tech team about handing off remaining things at a summer meeting. I've done a bunch of them already (as you can see from the checkboxes above).

[walshbr]

I'm moving onto the contrast issues now, though, and one issue is a little dicey. These are issues for people who have difficulty distinguishing text that has lower contrast with the background color. The shade we used for the PT logo fails contrast tests everywhere there is white text on it, which is pretty much everywhere. The two options for fixing it are:

a) change the color of the PT branding (easier technically) b) change the color of the text that appears across the site only if it's in the PT branded sections (more complicated technically, and also looks a little strange to my eye having played with it. Because you wind up with some sections that have white text and some with black text right next to each other, as on the front page).

Option A isn't necessarily as radical as it sounds - it just is a matter of darkening the current color so it's a little less pastel. Here's an example I mocked up in my own browser:

On the left you can see the original color - the right is the darker shade that has enough contrast and is easier to read. @DanielAlvesLABDH and @acrymble what do you think about this change? There are other contrast issues on the site that I need to take a look at, and I'll share things as they come up. But this was the main one that seemed to rise to the level of branding.

[walshbr]

We can also wait on this @acrymble until after the person you contacted has a chance to look at the site. Sorry - didn't mean to shift things under them. Just suddenly had a lot more time after my semester ended and was trying to get to things that had been on my list for a while!

[acrymble]

No need to wait @walshbr. PH has to fit around all of our lives. I'm grateful for the effort you've put into accessibility.

[walshbr]

Okay I think my work on this is done for now once the remaining pull requests are merged! Remaining work on the accessibility audit:

• [ ] we should consider using only blue alert/warning boxes instead of the current (green/red/blue). This can be fixed with a CSS fix to adjust the colour of the red and green ones.
• [ ] we should consider adopting icons to differentiate between different alert/warning box types. This is common in some publishers such as O'Reilly.
• [ ] screenreader has issues with nav bar - it appears that it's currently able to open the submenus, and the fix for it appeared to be more complicated than I can take on.
• [ ] night mode - it looks like the link color might need to be brightened against the night mode. But I'm not familiar enough with how the CSS is implemented there.
• [ ] PT branding - we need to decide on the PT branding. The color I proposed above is saved on a branch, and it wouldn't be hard to shift across the board if we decide on it. Just need to re-process the logo, but the rest of the coloring is easily changed. I can implement it if we get the OK from @DanielAlvesLABDH, @acrymble, and anyone else who might need to weigh in.
• [ ] Cannot skip to content: website should allow users to skip this content, like a Skip to Content link anchoring them directly to the main content on each page.
• [ ] Unlabelled form fields: Including clear, permanent visible labels allows users to know exactly what is expected of them when filling in form fields.

Beyond that, there remain a number of things that need to be manually checked. Everything I fixed was flagged by Chrome's dev tools as obvious issues. These may or may not be issues, so they'll need a human to check them. These will need to be checked on every page (you can look above for the list of pages I went through), but most of them tbh are probably determined by the general layouts for the site. So if we double check the layouts in general we should be good. I'll talk these through with the @programminghistorian/technical-team at our next meeting as a way of handing the remaining bits off.

• [ ] 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

[acrymble]

https://kdl.kcl.ac.uk/accessibility-statement/

This looks like a very comprehensive DH approach to accessibility so I wanted to share it.

[walshbr]

Ah this is interesting. I have some thoughts to discuss with the tech team on it. I like that it explicitly mentions non-compliance with certain things, rather than pretending like they don't exist. A lot of the things in that report are covered by what I have in the list above - but not everything.

[walshbr]

Just a note for @programminghistorian/technical-team to say that @acrymble shared the accessibility report from Dr. Amy Kavanagh with me. I reviewed it briefly - some of it is addressed by work I already did associated with this ticket, and some is captured by the remaining issues outstanding above. There are a few things from it that are more substantial to discuss at our next meeting as we discuss how to hand off the accessibility work to the next stage.

[acrymble]

@walshbr there are probably two distinct conversations. There were some technical recommendation in Dr. Kavanagh's report, but a lot that touch on editorial practice. As I've mentioned, I've got a MA student starting on a placement with us in June for a few weeks who I will have consider how we can adopt (and learn) the editorial stuff. If it's helpful I can have her extract the technical bits for this thread and then we don't need to hold up the process?

[walshbr]

That sounds good to me @acrymble!

[Amber202106]

Hi Brandon, Please check the below suggestions of Dr Kavenagh for navigation.

1. Keyboard Functionality: Not friendly to keyboard-only users: Three dropdown submenus can’t be operated by keyboard (also missing in screen reader).
2. Cannot skip to content: website should allow users to skip this content, like a Skip to Content link anchoring them directly to the main content on each page.
3. Text Contrast: Standard text (text that is smaller than 18pt/14pt and bold) must have a contrast ratio of at least 4.5:1 against its background. Large text (text that is 18pt/14pt and bold and larger) must have a contrast ratio of at least 3:1 against its background.
4. Unlabelled form fields: Including clear, permanent visible labels allows users to know exactly what is expected of them when filling in form fields.

[walshbr]

Thanks @Amber202106! Great to meet you. Just as a note - I think I addressed point 3 when doing a variety of pull requests a few weeks ago (I was sort of working on them at the same time or slightly after the report was written, I think). There certainly might still be issues with contrast, but I corrected a lot of contrast issues. So the bulk of our templates and layouts should hopefully be better now. Point one is already captured on our task list above, but I'll add points two and four!

[acrymble]

@walshbr we've now completed our final assessment (with @Amber202106) helping us to identify a number of issues for people with colour vision deficiency that touch on technical matters. The key ones are:

• [ ] we should consider using only blue alert/warning boxes instead of the current (green/red/blue). This can be fixed with a CSS fix to adjust the colour of the red and green ones.
• [ ] we should consider adopting icons to differentiate between different alert/warning box types. This is common in some publishers such as O'Reilly.

I've attached the report here, which includes a few examples and further resources. Colour Vision Deficiency - Technical.docx

I don't anticipate any further items for this ticket (sorry for the long process!)

[walshbr]

Thanks! I added these to the checklist above.

[walshbr]

Removed myself from assignment on this as we have a final meeting scheduled to chat about it before I leave the team, at which point it will be taken over by others.