[AH-28] Enhance application to follow A11y criterias

[Shagon1k]

Description

!! Work as AHurynovich-Accessibility or simply [AH-A]

Important to start with not "how" and "what" but with "why" and "for whom": check different disabilities types, how users struggle with them, which tools do they use, etc.

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion

!! Remember!
The important thing to understand about the TAB key, is that it is used to move from one operable item to the next. Any non-operable content in between will be ignored. So if a paragraph has some links inside a sentence, pressing TAB will just read out the links, not the rest of the sentence. The TAB key also stops at buttons and form inputs.
When the user wants to read the whole paragraph, they will proceed using the arrow keys ("browse" mode of Screen Readers, not "focus" mode). When dealing with a form or application-like UI, they can use the TAB key.
Page elements that are not interactive to mouse or touch users should not be made keyboard focusable (such as by using tabindex).
More details
More details 2

! Do not use tabindex values of 1 or greater to change the default keyboard navigation order. Think about logical TAB order (top-to-bottom, left-to-right) from the beginning, then left the Browser do all the job. Tab indexation change should be done only for exceptional cases.

W3C course with certification

https://www.w3.org/WAI/fundamentals/foundations-course/
https://courses.edx.org/certificates/ff5e044720d34b75922eecaf01440906

Guidelines

Perceivable - ability to find content:

• Text alternatives (all non-text content has it's alternatives, not only images but charts, diagrams, buttons, etc.) Note: Should be described not only based on content inside, but also content which it covers should be kept in mind + image functionality e.g. "My page homepage logo". Some images can have "alt" skipped in case adding it will only increase complexity (e.g. divider image) Remember: skipping alt !== having null one. Alt not null: informative, actionable images, alt null: decorative images.
• Media alternatives (videos\audios has captions, subtitles, text transcripts, audio descriptors, sign language)
• Adaptable (acceptable for different devices and it's orientations without lost information and structure (context) + well-read by Screen Readers (good Semantic, e.g. do not skip headings) )
• Distinguishable (content (text, images) can be separated from it's background - use https://contrast-ratio.com/ OR https://webaim.org/resources/contrastchecker/ OR https://color.adobe.com/create/color-accessibility . Recommended ration is 3-4.5 (based on large/small content))

Operable - ability to use application:

• Keyboard accessible (all parts of app accessible with only a keyboard. Remember: buttons for actions, links for moving to some content. AVOID keyboard traps. Focus locker or similar package could be used for modals\popups\navigation case.) TAB RULE: tab all, tab away, tab order, visual focus, all functionality by focus;
• Enough time (all content should have enough time to be watched)
• Avoid seizures and physical reactions (do not design content in a way that is known to cause seizures or physical reactions) So avoid flash more than 3 times in a second, animation covering large area of the screen, bright ones.
• Navigable (easy to navigate and understand - more about semantic) Note: unique <title> for each page is good practice (dash "|" can be used for complex titles, precise title first: "Contact Us | My Company") -> React Helmet
• Input Modalities (all parts of app accessible with mouse\touch)

Understandable - ability to understand each part of app (semantic):

• Readable (content is readable and easy to understand. Abbreviations could use tag )
• Predictable (app is predictable in how it operate. E.g. base structure is kept over the page and app navigation)
• Input assistance (easy to correct and avoid mistakes - validation and tips)

Robust - be compatible:

• Compatible (working for current and future accesstive technology):
  Write valid, semantic HTML (e.g. H1-H5 matters, HTML tags matters, etc.)
  Use ARIA labels to extend HTML (more applicable for interactive components)
  Use a11y testing tools

More information here

Notes

Tips:

• Once A11y plan created, it is worth to add a11y statement and place it somewhere on your web site (e.g. in Footer) in order to notify users that you follow it. Statement generator link: https://www.w3.org/WAI/planning/statements/generator/#create (additional info link)
• Add a11y to CI\CD pipeline
• Aria labels to check and add (aria-controls, aria-expanded, aria-role etc.)

Details

• Identify inputs and help browser autocomplete

Details

• Zooming (at least 200-300%) should be taken in to a count. Note: having 2 scrolling (vertical + horizontal) are not welcomed as in such way page become not so accessible and harder to read and understand
• Lower zoom (e.g. 50%) also matters for the people with tunnel vision
• Orientation should be taken in to a count
• Think about ability to remove animation (@no-animation mixin could be created)

Details

• New AAA standard is to buttons be at least 44x44
• For ON/OFF switchers or something like examples text notations should be used

Details

• Use "sr-only" elements for explanations. Such elements should also keep semantic (Headers, spans, navs, etc.)

Details

(Simple unseen elements could not be used as browser identifies them as "not needed" and possibly just skip)

• Use "aria-hidden=true" ARIA label in order to Screen Reader to skip content (in case no need to pass)
• Accessible SVG

Details

• Video embeds should not load on page load, only on demand need. Iframe with "srcdoc" attribute settled up could be used to handle this. DO NOT FORGET ABOUT TRANSCRIPTS FOR A11Y

Details

• FireFox browser has much better A11y built-in tools, Web Developer Chrome could be used as alternative
• Wave extension is really good one
• Additionally Chrome Lighthouse could be used to test A11y
• Screen Reader extension
• Sometimes it is worth to add "Skip smth" hidden link (e.g. "Skip navigation")

Details

• Managing programmatically onBlur event it is worth to use setTimeout as wrapper to callback. It is valuable as we need to first check if another child of the element has received focus as the blur event fires prior to the new focus event
• Also worth to add some a11y linters like jsx-eslint/jsx-a11y, stylelint-a11y
• Don't forget to use "role" attribute in addition to ARIA labels

Details

• Test a11y also using testing-library/dom, testing-library/jest-dom, user-event
  Inspire example: https://github.com/denis-biruk/a11y-test-tabs

Details

• Check google.com tabulation for inspiration about skip link and "how to" for people with disabilities

• Tooltips should not contain really important information as it is not always accessible (e.g. for users using Screen Magnification)

• Use a11y anchors to skip over the site for more welcomed interface:
  

• Android TalkBack feature can be also used to check site A11y

• When opening Popup the focus should automatically go to "X" button (close) to provide USER easy possibility to close in case unintentional opening (the only exception happens if there are some focusable items before "X" button, then focus should be set to them in order not to skip when TAB navigate);

• Button for the action, Link for the navigation;

• NO necessity to specify both "ariaLabel" and "title": in such case both will be read by Screen Reader;

• avoid outline: 0`outline: none`. In addition to the default outline, you can use CSS to make the focus indicator more visually apparent and keyboard-friendly by ensuring the focus indicator is highly visible with sufficient contrast, and by adding a background color or other visual focus style to links and other interactive controls. The outline can be styled to match your site design but should be readily detected when navigating with the Tab key.

A11y settings popup

• A11y settings popup could be created as an option. It could be used e.g. for changing text font to more accessible one, remove animations, activate more color-friendly theme, change font size, change basic margins, text line-height and line-spacing, reduced number of images and content etc.
• CSS-specific variables (e.g. preferable font size) could be stored by A11y settings service in CSS variables to automatically work only on CSS basis (https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties)
• Opening popup will display a list of different disabilities people might have (cognitive, low visual, absence of visual, etc.) and application will apply changes based on chosen

A11y CI/CD automation

There are a number of tools. Worth to check and add to pipeline. Example: axe-core
Cypress also could be used to test A11y in a couple with Axe. https://www.npmjs.com/package/cypress-axe