search

cambiatus / frontend

Cambiatus Web based frontend using Elm
https://app.cambiatus.io
GNU Affero General Public License v3.0
24 stars 15 forks source link

Use more accessible HTML #638

Open henriquecbuss opened 3 years ago

henriquecbuss commented 3 years ago

What we have We don't really consider people with disabilities when developing our app. We don't necessarily follow best practices for screen readers (we don't necessarily use semantic HTML, etc.), and maybe other kinds of disabilities.

Proposal We have enough tools to enforce best practices (see the "How" section below), so we should use/create them. These tools could help us enforce using semantic HTML, use some ARIA attributes, etc.

Why To make our webapp more accessible to everyone. It could also help avoiding some issues that come from using wrong HTML tags

How So far I've had two ideas:

  1. Create an elm-review rule which would flag incorrect usages of certain HTML elements, such as images without an alt attribute (we would need to create these rules, and that would probably take a long time to make it good :sweat_smile: ).
  2. Use Elm's type system to enforce correct usages. There is already an Elm package that does this. And then to flag all occurrences of regular elm/html usage, we could use NeoVier/elm-review-no-function-outside-of-modules.

Additional context

lucca65 commented 3 years ago

This is nice! It would be a thing very aligned with our values, and could fit right if we break it down a little bit, maybe by saving some time to explore and set what our milestones would be to make it work!

henriquecbuss commented 3 years ago

Yeah, this is going to be a really big one, and it's going to affect the entire app... I'm not sure what's a good way to break it into smaller pieces though... maybe we do it per element/group of elements? (First we do imgs, then divs, then h1-h6, etc.)

Also, it would be nice to explore different options on how to do this (using tesk9/accessible-html, creating an elm-review package, etc), and I'm definitely open to suggestions! We should have that well thought out before we start working on this, since it's such a big effort

gorda0 commented 2 years ago

Following this thread, here are some points about accessibility on login page:

Header 1 - There's no <nav> tag, but there's a <a> tag to redirect the user. I have tested on chrome inspector adding the <nav> tag and didn't break anything. 2 - There's no alt tag on logo, resulting screen readers to read the image url. 3 - The i18n button isn't accessible via tab(desktop) or swipe(mobile). I have also tested removing the tabindex=-1 on this button and it worked properly. 3.1 - After removing the tabindex, the modal doesn't work properly, it leaks out of the content. Modals should trap focus until the user press Esc or do something that should close the current modal.

"i'm already a member" button 1 - It has link semantic but visualy it's a button. 2 - contrast between background(orange) and text color(white) doesn't meet any of WCAG expected contrast ratios.

I've tested using Chrome DevTools, NVDA, Orca, VoiceOver and Talkback. I'm having trouble to enter another screen due to not having a 12 word key, and lack of knowledge on Elm.

henriquecbuss commented 2 years ago

Thank you so much for your comment and thorough testing @gorda0, those are some very good points!

I'm having trouble to enter another screen due to not having a 12 word key

That's because we default to a community that requires an invitation (@lucca65 maybe we should change that on the Cambiatus community on staging). If you want to create an account, you can use this invitation link: https://cambiatus.staging.cambiatus.io/invite/lPeJWn (or http://cambiatus.staging.localhost:3000/invite/lPeJWn if you're running the app locally), or this other test community, which doesn't require an invitation: https://buss.staging.cambiatus.io (or http://buss.staging.localhost:3000/login if you're running the app locally), just remember to save your 12 words so you can log back in if you log out. Once you have an account, you can go to /community/new, and create a new community for you to play with!

If you want to work on something on the frontend, feel free to pick up (or ask questions about) any issue that doesn't have someone assigned, we can help you with Elm, or anything related to our app!

henriquecbuss commented 2 years ago

2 - contrast between background(orange) and text color(white) doesn't meet any of WCAG expected contrast ratios.

I was actually stumped by this, and ended up stumbling on a r/webdev post, specifically on a comment that linked to an article about The Myths of Color Contrast Accessibility. The author of the article is a bit harsh, and although I agree we could have some better contrast, I also agree with the author in that we don't always need to follow WCAG blindly. But anywany, that's a great topic for discussion! @heltonlr @juramos-2020 @rafachadud you might find this thread interesting, it's very much related to the recent accessibility changes to screens we've been making (#622)!

gorda0 commented 2 years ago

we don't always need to follow WCAG blindly.

If cambiatus isn't participating in or leading any color research, so it's just be better to follow WCAG2.1 standards. Not blindly of course, we should always search about "rules" imposed to us, as you did. But WCAG2.1 will make sure the application will be accessible to (at least) the majority of the minority. And we can't ignore the research W3C has made on this field for all this years, side by side with the accessibility community.

Following WCAG2.1 also is a good way to avoid problems with the LBI law. It's not the main point of accessibility standards, but it's equaly important to note. As far as i know, the LBI only consider the WCAG1.1 as required, unfortunately. But i believe the rest of the world is already using WCAG2.1(AAA) standards. There are some comments above the article that mentions similar law implications too.

Also, reading the comments above the article, people shown very divided or different opinions. It just does not looks secure to follow, at least looks less secure than just rethink the button color(or the text color) and meet WCAG2.1 standards.

gorda0 commented 2 years ago

I have registered on the staging platform, as soon as possible i will return with a document pointing other accessiblity points. I'm also avaiable for meetings to discuss this topic, lucca has my personal contact and in my profile there's a public e-mail too! I really would appreciate to aggregate in something.

henriquecbuss commented 2 years ago

Nice, thank you! Let us know if you need anything from us! I've been tackling some accessibility throughout our app, and it's been little by little, and we're definitely a long way from being done, so this will definitely help us a lot!

gorda0 commented 2 years ago

Another problem i forgot to mention.. At the 12 word textfield, while the value isn't valid it shows a form error message. This message was not being read by NVDA and Orca. It should be fixed by inserting an attribute aria-live="assertive | polite", or role="alert"(which will use aria-live assertive but better compatibility with screen readers). I really think in this particular problem the fix would be use the aria-live="polite" attribute, at work we had some bad feedback from our disabled QA analysts/validators on a similar form problem. We tried to use role="alert" but they returned that this kind of alert message should be read by the screen readers everytime the user pauses typing, until the message dissappears or the user exit the input.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions

https://www.w3.org/TR/WCAG20-TECHS/ARIA19.html https://www.digitala11y.com/aria-atomic-properties/

https://pauljadam.com/demos/aria-atomic-relevant.html

im studying elm when i have a free time, sorry for the generic comments of how to apply something.