blazebarsamian commented 6 years ago

In order to follow WCAG standards, we need to make a few updates to our components to provide a more accessible experience.

See education ticket that covers the standards.

Heres a list of where these updates need to happen:

Language:

[x] Add language to Possums html tag

Inputs:

[x] Inputs should have a name="" attribute
[x] File Upload inputs should have a name and/or role

Nav:

[x] Nav links should have role=" " attribute

Menu:

[x] Menu links should have role="menu" attribute

Links styled as buttons:

[ ] Should have a role="" attribute so you can declare the role as role="button"

Flash message, Tooltips, Modals, dropdowns, CloseButton:

[ ] dismissible: (content that is shown on :hover or on :focus must be dismissible via keyboard actions without requiring the user to change focus)
[ ] hoverable: (content that shows on :hover must remain showing if user mouses over content)
[ ] Also need a way to close out of them if they overlap text. Possible solutions:
- Esc Key for dropdowns
- Add close button to tool tips. Make tool tips only show on click (?) and then exit when the user clicks the close button.
- All flash messages should include a close button. And then can also be closed by hitting the ESC key. (Would there ever be an instance where theres an flash message and a modal open at the same time? Might want to consider how the esc key would work if there were ever both open)
[x] Dropdown Selects are dismissible by hitting the esc key

Images:

[ ] Need to have alt text

Buttons:

[ ] Role if its a submit button?
[ ] Name for everything else?
Look into what WCAG requires for toggle buttons.

Expanding columns:

[ ] Add the ability to collapse using the esc key

Lintomat checks to add:

All Images, videos, ect (Non-text content) have text alternatives
(Idk if this is something that lintomat can check for or not) if theres moving content used such as image carousel or background video, make sure there's a way to pause or stop the movement.
Page Title: Each time a new page is created, check that it has a title.
During project set up, check to make sure that the language of the page is set <html lang="en">
All inputs that require a certain format must have error messages set up.
If its possible: check for contrast ratio: Contrast ratio between text and background is at least 4.5:1
Check that all Inputs (stacked and/or unstacked) have a name="" assigned to them
Check that all FileInputs have a name="" assigned to them
Check that all InputGroups have a name="" assigned to the Input inside <InputGroup.Field>
Check that every link inside a <Menu.Item> has a role="menu" assigned to them (This goes for the menu component as well as the topbar component)
All links styled as a button have a role="button"
When <CloseButton> component is used, check to make sure whatever it is closing is also dismissible with the esc key
- Background: the close button component is pretty much just a style thing which is why it doesn't function on the possum site

NEW Rules to add to lintomat after March 30th:

Line height: at least 1.5 times the font size;
Spacing following paragraphs to at least 2 times the font size;
Letter spacing (tracking) to at least 0.12 times the font size;
Word spacing to at least 0.16 times the font size.
Target Size: 44px target areas

blazebarsamian commented 6 years ago

Other Notes:

WAI-Aria Practices:

Not required but something to think about.

Buttons

[ ] Toggle Buttons: two-state buttons that can be either on (pressed) or off (not pressed).
- To tell assititive technologies that a button is a toggle button, specify a value (true or false) for the attribute aria-pressed
  - activating it changes the value to true and then clicking it again changes the value back to false ^ add this to the Expanding columns and to the drawer(?) too-- basically anything that toggles will need this.
[ ] Menu Button: a button is revealed to assistive technologies as a menu button if it has the property aria-haspopup set to either menu or true.
- https://www.w3.org/TR/wai-aria-practices/#menubutton
[ ] I think buttons need to have a default role attribute set to "button" but the ability for that role to be changed. https://www.w3.org/TR/wai-aria-practices/#button

programmatically set states, properties, and values
- This includes non-standard (scripted) buttons, input fields, and other controls.

Untrapping Keyboard users:

All parts of the site must be reachable by keyboard
User must also be able to get away from all parts of the site
Check that all third-party adverts or widgets are accessible (usually theyre not)

Links:

If a link is an image, the alt text of the image makes the link purpose clear
Links going to the same destination should have the same description. Links going to different destinations should have different descriptions.

On Focus:

No automatic pop-ups without the using taking action (such a clicking)
Focus never jumps to another element automatically
Elements can change on focus if context doesn't change (i.e: when nav options drop down when you hover over an item--> thats not a change of context)

On Input:

Don't let forms automatically submit without users clicking submit.
When a forms receives input, it must not auto skip to the next field or automatically submit.
Use a control like a submit button

Form Errors:

Show and describe the required format whether in the placeholder (not positive if thats acceptable? screen readers read placeholders, right?) or in the label or help text.
Build forms to accept variations of the formats you prefer
highlight mistakes in forms with colors and symbols
Don't clear a form if the user makes a mistake. Save the information and allow the user to edit their mistake and continue

Form Labels:

Mark required fields with an icon and explain what the icon means before the form.
When a field has a specific format, give an example in the label.
Keep labels and instructions simple.

Name, Role, Value:

Majority of potential issues will come from third-parties

brittanygay commented 6 years ago

@blazebarsamian @CheetoMao I'm assigning myself to help out with some of the checklist since I have some spare time this week!

blazebarsamian commented 6 years ago

yes please @brittanygay!! Im supposed to start working on these updates this week. I feel like I'm missing more of the name, value, role examples that we need to include but I haven't found examples.

I was about to start looking into how to add props to our input components to add name, role, ect.

blazebarsamian commented 6 years ago

I've been messing with some form elements and using voice over to read off the page and test.

When I inspect the elements, the name and role attributes are there but are not being read. Looking into this more now.

blazebarsamian commented 6 years ago

From what I understandl the purpose of name, role and value is just for the software to understand what the custom controls are so the screen reader is not confused with a div or span.

https://accessibility.huit.harvard.edu/provide-name-role-and-value-information

I checked our checkboxes using the wave accessibility tester and they pass even though the voice over doesnt verbally read out the names of the checkboxes.

screen shot 2018-04-10 at 3 51 18 pm

blazebarsamian commented 6 years ago

Update: I'm going to move this back to icebox until I can get back to work on it (It looks like ill have some time this week).

I need to get someone to pair with me for the esc-to-dismiss functionality for modals. I've tried to figure it out myself but I think I'm missing something.

revelry-stalebot[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

bryanjos commented 5 years ago

Inputs should have a name="" attribute

In most cases this is fine. There will be cases when this is not a good idea to do. Having a name attribute for an input in a form means the value will be sent to the server when submitted. For things like credit cards, crypto secrets, and personal id numbers, we may not want to send them to the server.

That's the only caveat. Just wanted to make sure to say it out loud.

revelry-stalebot[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

revelrylabs / harmonium

As revelry, I want to make updates to certain components in order to follow WCAG Standards. #188

Lintomat checks to add:

Other Notes:

WAI-Aria Practices:

Buttons

Untrapping Keyboard users:

Links:

On Focus:

On Input:

Form Errors:

Form Labels:

Name, Role, Value: