[WIP] Document accessibility issues

[kylemh]

This issue is marked as BLOCKED because it is a placeholder to spread out all below into multiple issues. Please do not file a PR to correct this issue.

This isn't a traditional issue that matches our scheme, but I wanted to get some helpful emails I received out in the open. I can split these up to more manageable issues within the next 24 hours, but if somebody else is available, they can do the same (feel free to edit OP). I'm not sure of her last name, but thank you to Melissa for emailing Operation Code staff on these issues! Any bold text are my own personal interjections.

Note: I'm hoping we fixed this in a recent PR

• style links (within paragraphs) so they stand out as links. Right now they are the same color and font style as the regular text. Though the font family is different, the difference is nearly imperceivable, and I would lake to make it obvious they are links.

• make the sign up form more accessible. Currently, there are no labels. Placeholders are not label replacements. Using placeholder text instead of labels hinders both sighted users and users who are reliant on screenreaders. Placeholder text also (even with labels) in general should only be used of a hint is actually needed, for example how to format a date or credit card number. For things that are self-explanatory (name, email, password), they are not needed and often negatively affect user experience. Many users see placeholder text and assume the fields have already been filled out. I would also like to move the paragraph outside of the form, since it is not a part of the form. The form changes I propose would look something like this: https://i.imgur.com/5OCIIiO.jpg

After this email, I asked about integrating AxE into our workflow, and asked if it would solve every issue. Clearly she is very knowledgable on accessibility.
AxE: https://github.com/dequelabs/axe-core/blob/develop/README.md

I've never used (though have heard of) AxE except for in-browser audits, but I can tell you this: you will still need manual accessibility testing. AxE can only detect certain issues, like color contrast, sufficient link text, missing form labels, images without alt attributes, etc.

Because this might get a bit winded, in short: no, AxE will not solve all current and future issues. It will detect many issues and is a great tool to integrate, but manual testing will still be needed.

For example, Chrome DevTools now uses AxE for its accessibility audit feature. Running an audit on your home page, you score a 94, failing for some link text and color contrast issues. What AxE did not pick up was that you have an image with text, but no way for a screen reader (or search engine) to access the text. You have an alt attribute which says "gala banner", so AxE sees "this is an image with an alt attribute. It passes!" without realizing the image contains important content which is inaccessible for non-sighted users (or for sighted users if the image fails to load).

This type of accessibility issue can only be found with manual testing. Some other things which need manual testing, some of which I found to be issues on the OC website:

• making sure there is a focus style for all focusable elements

• making sure links are distinguishable from regular text

• making sure everything a user can do with a mouse can also be done with the keyboard

• make sure any text over images is legible (not just contrast, but depending on how busy the image is)

• focus management (this isn't an issue on your site, as far as I can see, but for example if you were to ever include a modal, you would need to make sure focus gets trapped inside of the modal while it's open so someone using the keyboard to navigate does not accidentally tab out of the modal)

I am not sure if this qualifies technically as an accessibility issue, but it is a user experience issue: if using hover styles, you should make sure the hover style is different enough from the default style to be noticed. For example, I notice the hover style of the social media icons changes opacity slightly, but if you hover one and look at the non-hovered icon next to it, I think you will notice it's very hard to tell which is actually the active element.

On the page with checkboxes to select languages and disciplines, I noticed that the labels are not associated with the checkboxes. This affects screenreader users as well as regular users used to clicking a label to check the checkbox. This is happening because while the labels include "for" attributes, they are pointing to the element with the id of "languages", which is the label element that says "select languages'. Instead the labels most point to their individual input. For example, the first label "Javascript" should have for="Javascript", so it is associated with the Javascript checkbox.

Also, the label elements being used to title sections ("select any languages..."), is not correct, as far as I can tell:
https://w3c.github.io/html/sec-forms.html#the-label-element

Labels are for individual input elements. In this case, what you want is a fieldset and legend, I believe.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fieldset

[meowwwls]

Would it help within this issue where all of the issues are being documented, to break them down into categories of UI/Design/CSS, Structure/HTML/ARIA, Behavior, etc.? If so I can work on that later tonight / early tomorrow and then start filing individual issues.

[kylemh]

@meowwwls I think the best way to breakdown the issues is to group them by page so that people can conglomerate in resolutions to neighboring code blocks. Open to suggestions!

[meowwwls]

@kylemh Great! Thanks. For issues that span across the entire site (links within paragraphs not being distinguishable enough, or the contrast of the social media icons not being sufficient, for example), should they be grouped / labeled at all, or just listed as general issues to addressed?

[kylemh]

The global a tag styles within p elements, can be changed in src/index.css

The social media icons are under src/shared/components/socialMedia/socialMediaItem and the stylesheets there can be edited to change contrast.

I don't know if there's an exact science to splitting them up, but keeping them small enough so that somebody may want to immediately contribute a resolution is my only desire.

[meowwwls]

Got it. Thank you!

[dmarchante]

@kylemh what is the status on this?

[kylemh]

This is definitely epic status. I'm paying much more attention to accessibility on the rewrite and have drawn from this issue a few times. The initial ticket could be split out into multiple, smaller, more accomplishable tasks hence the [WIP]