chapter
chapter copied to clipboard
freeCodeCamp
Accessibility
Keeping accessibility in mind
As we are creating a new application that brings together a variety of people without a paywall cough Wework cough, we need to keep accessibility in mind. Having the application being at least AA WCAG 2.1 compliant would ensure we can at least reach users with some level of visual or physical impairment. By adding minimal tweaks here and there, we can reach more by removing barriers to the platform, hence "accessibility".
Accessibility is the law now - Quincy Larson
Since FCC is not owned or used federally, we can skip Section 508 but I added it below for reference if anyone is interested in seeing where it all started. If anyone has additional ideas on implementation or other helpful comments, please do share and feel free to make changes as needed.
A Practical Approach
Web Accessibility does not get enough coverage in CS or Web Dev courses, but it makes a huge difference for a lot of users online. - Roman Mikhailov
- Color Contrast: Run your color palette through Toolness Accessible Color Matrix or Web Aim Color Contrast Checker. You'll learn that white text on a yellow background won't cut it.
-
Use Semantic markup: use HTML5 tags as they were intended (not using
<h1>for it's size or<div>where<section>,<article>or<footer>would be appropiate), use CSS for the rest - Screen readers: Use an actual screen reader like NVDA for Windows or VoiceOver for Mac alongside ChromeLens to mimic the experience of a person with visual impairments and see if you can still find what you need
- Aria Labels, tooltips, titles, and alt properties: making sure important content is not lost if images don't load, ensure the form input fields have proper aria roles, and let users know that a dialog box or modal has been opened and how to close it
- Navigable Forms: For keyboard-heavy/only users, forms should follow a logical tab order and should display appropriate feedback if values are missing or entered incorrectly.
- Skip to Content button: avoids the user having to listen to every dropdown option in the navigation when using a screen reader
- Zoom: Some users need to enlarge content, make sure things don't fall to pieces when they do
- CPU Throttling: One mistake devs often make is developing Frontend heavy sites on super fast computers, completely oblivious to the fact that their site is hanging on entry level laptops. Use chrome to throttle cpu and test performance. - @wellpaidgeek
- Font size: 16px is the web standard. Let's save the light grey 10px font on a white background for things we intentionally don't want users to see
Tools
a11y Quick Tests Axe Accessibility Chrome extension Function Accessibility Evaluator Toolness Accessible Color Matrix Web Aim Color Contrast Checker ChromeLens chrome extension - seeing through another's eyes About Screen Readers: Narrator, AudioVox, NVDA, JAWS - prepare to be overwhelmed
References
Overview (with videos) Top Questions about Accessibility W3 Developing Tips Google Overview on Design and UX - specifically ARIA labels WCAG Quick Reference Quick tips using manual testing
Extra
This is awesome! When we decide on a spec for this I (or someone) will add this to the docs.
Should probably also need forms to follow a logical tab order, and ensure the input fields have the proper aria role
I think we should advocate for using actual screen readers for testing as well as ChromeLens. On a Windows machine, you can download NVDA for free. On Mac, you can use VoiceOver - which is built in to your machine. This is much more accurate to what a user will end up with.
Also, can we add the Toolness Accessible Color Matrix to the resources? It's pretty handy for showing what colors will and will not work together for AA compliance.
Also, I would love to contribute to the accessibility effort here.
I listed an article that referenced other screen readers but explicitly added those two under the Practical section + added your @Critchkn note on tab indexes for forms. Also @ryandudek , that Color Matrix is banging, added as well.
Can we cross-reference the issues this is most likely to impact by # in'g them here, or # 'ing this on those threads? #5 has accessibility in the first post, so it seems that one is related at a minimum. Not sure how this would apply to mobile clients, and that could be further off, but maybe reference this to the mobile client thread too?
Moving the list of accessibility interested folks here from the #1 comment
- @timi-codes
- @ceciliaconsta3
- Critchkn on Discord
- @ryandudek
- @maiya-22
- codedawg on Discord
- @QuincyLarson said "accessiblity is the law now"" so he's onboard
We've started asking folks to update their Discord nickname to match their Github, but for earlier names you may need to search the messages to find and reach out to the Discord names. I'll defer to this group to make those connections.
Thanks @ceciliaconsta3 it is a great suggestion. Having accessibility functions is definitely needed for a inclusive community app.
Maybe we can make a QA check-list that all new features need to be referenced against, to make sure that they are compliant with accessibility standards.
And we can comment about how they were made compliant, so that the community can learn about this essential skill, as we go.
I read Morten Rand-Hendrickson talking about how accessibility is naturally built into the web, & we design it out. So learning about how to adapt the tooling to these native capabilities would be helpful.
@maiya-22 That's a great idea. A checklist or design guide is even more practical. Though I do think it would be more efficient if everyone runs the recommended tools. The tools, checkers, guides, and applications above should provide more than enough information, rather than re-inventing the wheel.
Is there anything I can do to help? I'll have some free time tomorrow and sunday
@Critchkn Don't think so at the moment. I propose with every front end PR someone can volunteer as designated "accessibility checker". So for now, maybe adding yourself as an additional peer reviewer would help.
I've been advocating to use React Native Web for producing the web client, as it allows us to use a single React Native codebase to produce both a mobile client (#20) and a web client (not to mention, by following a React Native-based architecture, we could incrementally add ports for other potential client platforms like desktop). I'd like to advocate it as a solution for cross-platform accessibility, too.
React Native includes accessibility features, many of which were filled in by the Amazon team, so they should be industry-standard. By implementing accessibility in a React Native codebase, it would be inherited across all other platforms that React Native ports exist for, provided the given port is thorough. React Native Web implements accessibility thoroughly, and it powers the Twitter website (which purports to be accessible). React Native Windows and React Native macOS are both developed by Microsoft and used in Office and other products, so I think that accessibility won't have been neglected for those ports, either.
Above all, by using a single framework to implement accessibility, we wouldn't need a dedicated accessibility expert for each individual client platform. We'd be able to focus all efforts in the same place and not have inconsistencies in accessibility between platforms merely due to a lack of platform-specific understanding.
I'd be interested in what an accessibility expert's opinion is on the Twitter website and native mobile apps. If both seem adequately accessible, it would be a mark of confidence for a client stack involving React Native and React Native Web.
#144 could use input from the Accessibility-focused folks in this thread on where to draw the line on browser support. I'm making the assumption that socio-economic situation, and therefore available computers / devices, falls within the domain of Accessibility.
This is a UX / usability note, and not directly related to accessibility. Though, I'm imagining accessibility and UX will be reviewed before MVP, and continuously afterwards, so I wanted to leave a breadcrumb to things we've already discussed.
Here are earlier conversations about switches vs checkboxes and when to use dropdowns vs other things.
I would like to contribute to improve accessibility. Is there anything that I can pick up?
@Chirag2193 yes, we don't have specific tasks, but there is a list of best practices and links to resources at the top of this thread.
We have not directly focused on the accessibility of the development copy of the site, so any small pull requests that address the best practices would be appreciated.
We could use tools like Andi, axe and/or Wave to check the sites current accessibility holes and put together a to-do list
On Sun, Apr 30, 2023, 5:33 AM Chirag2193 @.***> wrote:
I would like to contribute to improve accessibility. Is there anything that I can pick up?
— Reply to this email directly, view it on GitHub https://github.com/freeCodeCamp/chapter/issues/65#issuecomment-1528991511, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKJ74JENG4ELTO2SD7SPDX3XDY5Y3ANCNFSM4JBQCGXA . You are receiving this because you were mentioned.Message ID: @.***>
Issue: Alternative Text for Images
I see that images associated with events do not yet have alternative texts. I noticed that when creating an event, we ask for the image url, but it would be a good idea to also ask for alternate text. If the user does not give an alternative text, we can set a default text for it.
As an MVP, it would be excellent to include a default alternative text similar to 'Image describing the event' and eventually make it configurable so that the image uploader can add context to the image via the alternative text field.
Issue: Buttons don't meet color contrast WCAG expectations
Currently, when running tests with the axe extension tool. The buttons do not appear to fulfil the colour contrast ratio. However, I don't consider this a problem because it's not far from 4.15 and is currently 4.02. Thoughts?
It looks like the button is --chakra-colors-blue-500 and there are other, darker color variables like --chakra-colors-blue-600, --chakra-colors-blue-700. I don't think anybody will be upset if we move the buttons to the next level or two of darkeness to see if that fixes the contrast ratio.
I agree with default alt text, like
Event Thumbnail for {events.name} on routes like https://chapter.freecodecamp.org/chapters/# Event Banner for {events.name} on routes like https://chapter.freecodecamp.org/events/#
I'm honestly big against vague alt txt like that because it needs to be descriptive if its important and empty (alt or alt="") if its decorative. Event Banner or Event Thumbnail will confuse AT users.
Kind Regards, Robert Elliott CEO P +1 (615) 669 5552 W aedevdesigns.com
31
On Mon, May 1, 2023 at 10:40 AM Jim Ciallella @.***> wrote:
It looks like the button is --chakra-colors-blue-500 and there are other, darker color variables like --chakra-colors-blue-600, --chakra-colors-blue-700. I don't think anybody will be upset if we move the buttons to the next level or two of darkeness to see if that fixes the contrast ratio.
I agree with default alt text, like
Event Thumbnail for {events.name http://events.name} on routes like https://chapter.freecodecamp.org/chapters/# Event Banner for {events.name http://events.name} on routes like https://chapter.freecodecamp.org/events/#
— Reply to this email directly, view it on GitHub https://github.com/freeCodeCamp/chapter/issues/65#issuecomment-1529847574, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKJ74JF46SJZYNLHP5ZEQPDXD7KN5ANCNFSM4JBQCGXA . You are receiving this because you were mentioned.Message ID: @.***>
@AEDesigns the point is take, but we don't have an interface for setting custom text on images and that may not make it into the MVP.
Is the suggestion to do nothing instead of using something that's at least mildly descriptive of what's on the screen?
Yes, because if we add alt text that isn't descriptive then we aren't fixing anything. We're just replacing one error with another.
Kind Regards, Robert Elliott CEO P +1 (615) 669 5552 W aedevdesigns.com
31
On Mon, May 1, 2023 at 11:34 AM Jim Ciallella @.***> wrote:
@AEDesigns https://github.com/AEDesigns the point is take, but we don't have an interface for setting custom text on images and that may not make it into the MVP.
Is the suggestion to do nothing instead of using something that's at least mildly descriptive of what's on the screen?
— Reply to this email directly, view it on GitHub https://github.com/freeCodeCamp/chapter/issues/65#issuecomment-1529926696, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKJ74JFFTVNBVAYFBXOQ37DXD7QYFANCNFSM4JBQCGXA . You are receiving this because you were mentioned.Message ID: @.***>
Well, I think we purposely avoided images on other pages, like the Chapters page, because it was unclear if they were adding a lot of value. Though, having pages without images often comes off as stark when compared to a typical website.
I'd wager most of the event thumbnail or banner images used by organizers are going to be mildly representative of the event. For example, on the first group of events on my Meetup feed you have things like a photo of tacos with an Alt text of "Social Event at White Duck Taco Shop on Airport Rd" and I'd imagine Meetup doesn't give the ability to set alt text.
We decidedly don't want to be like Meetup, or base our decisions on what they do, but in a case like this, is it better to expect an organizer to put "Three Tacos on a Wooden Tray" as alt text for a photo, or just exclude the text?
Here is an image of Meetup.com showing a photo of three tacos and, below that, the underlying browser HTML source code showing a generic alt text that does not describe the actual contents of the photo.
