Accessibility about chapter HOT 24 OPEN

This is awesome! When we decide on a spec for this I (or someone) will add this to the docs.

from chapter.

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.

from chapter.

Should probably also need forms to follow a logical tab order, and ensure the input fields have the proper aria role

from chapter.

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

from chapter.

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

from chapter.

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.

from chapter.

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.

from chapter.

Thanks @ceciliaconsta3 it is a great suggestion. Having accessibility functions is definitely needed for a inclusive community app.

from chapter.

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?

from chapter.

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.

from chapter.

Is there anything I can do to help? I'll have some free time tomorrow and sunday

from chapter.

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.

from chapter.

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

from chapter.

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.

from chapter.

I would like to contribute to improve accessibility. Is there anything that I can pick up?

from chapter.

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

from chapter.

from chapter.

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.

from chapter.

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?

from chapter.

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/#

from chapter.

from chapter.

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

from chapter.

from chapter.

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.

from chapter.