Slide 1

Slide 1 text

WEB ACCESSIBILITY Răzvan Roșu /razvan-rosu /razvan-rosu @rzvn_rosu

Slide 2

Slide 2 text

What is Web Accessibility? Myth Accessibility is often viewed as making your site work on screen readers. What Accessibility really is Accessibility is a subset of UX focused on making your websites usable by the widest range of people possible, including those who have disabilities.

Slide 3

Slide 3 text

Why should we care about Accessibility? The main reason is the concept’s definition itself: we want our application to be usable by as many people as possible. We should also care due to good ethics and laws and regulations.

Slide 4

Slide 4 text

Statistics: Persons with disabilities in Europe are a significant group: ● 10% to 15% of the total population ● 50 to 75 million people in EU27* ● There is a strong correlation between disability and ageing (numbers increase with demographic change) Source: Labour Force Survey (European Commission-Eurostat 2002) http://ec.europa.eu/ipg/standards/accessibility/index_en.htm *EU27 - European Union during 2007 - 2013 when it had 27 countries - European Union after 2016 without UK due to Brexit

Slide 5

Slide 5 text

Disabilities to account for: 1. Blindness and vision impairment 2. Deaf and hard of hearing 3. Physical disabilities 4. Cognitive disabilities

Slide 6

Slide 6 text

1. Blindness and Vision impairment ● Total blindness ● Legally blind ● Color blindness

Slide 7

Slide 7 text

1. Blindness and Vision impairment A person is legally blind if: - his/her visual acuity is less than 20/200 At the distance of 20 feet (~6m), a person doesn’t see a text, which can be seen at 200 feet (~60m) by a person with perfect eyesight. - his/her view angle is less than 20 degrees https://www.allaboutvision.com/lowvision/legally-blind.htm

Slide 8

Slide 8 text

1. Blindness and Vision impairment Visual acuity examples:

Slide 9

Slide 9 text

1. Blindness and Vision impairment Visual acuity examples:

Slide 10

Slide 10 text

1. Blindness and Vision impairment View angle examples:

Slide 11

Slide 11 text

1. Blindness and Vision impairment View angle examples:

Slide 12

Slide 12 text

1. Blindness and Vision impairment Color blindness is a deficiency in distinguishing colors. The ideal contrast ratio between two colors is of 4.5:1 https://webaim.org/resources/contrastchecker/ Chrome extension for live color blindness simulation: https://chrome.google.com/webstore/detail/i-want-to-see-like-the-co/jebeedfnielkcjlcokhiobodkjjpbjia Side by side color blind comparison tool: https://www.toptal.com/designers/colorfilter

Slide 13

Slide 13 text

1. Blindness and Vision impairment Accessibility solutions and tools: ● Braille ● Screen readers ● Screen magnifiers ● Scaling the UI (entirely) ● Font size increase (only) ● High contrast Themes Humanware Braillant BI 40 Freedom Scientific JAWS

Slide 14

Slide 14 text

Disabilities to account for: 1. Blindness and vision impairment 2. Deaf and hard of hearing 3. Physical disabilities 4. Cognitive disabilities

Slide 15

Slide 15 text

2. Deaf and hard of hearing People with a hearing disability rely heavily on visual information. We should provide audio and video content with a description and subtitles (closed captions). Do not autoplay media content. An interview with a Deaf academic librarian on web experience: https://developer.paciellogroup.com/blog/2017/02/sounding-out-the-web-accessibility-for-deaf-and-hard-of-hearing-people-part-1/ https://developer.paciellogroup.com/blog/2017/03/sounding-out-the-web-accessibility-for-deaf-and-hard-of-hearing-people-part-2/

Slide 16

Slide 16 text

Disabilities to account for: 1. Blindness and vision impairment 2. Deaf and hard of hearing 3. Physical disabilities 4. Cognitive disabilities

Slide 17

Slide 17 text

3. Physical disabilities For physical disabilities, we need to take into account users that don’t navigate web pages with the traditional mouse (along a keyboard). Ensuring the possibility to navigate by keyboard exclusively should be good enough for the time being, but have in mind other means such as Eye Controlling. https://www.tobii.com/tech/ https://arstechnica.com/gadgets/2017/08/windows-adding-eye-control-to-boost-accessibility/

Slide 18

Slide 18 text

Disabilities to account for: 1. Blindness and vision impairment 2. Deaf and hard of hearing 3. Physical disabilities 4. Cognitive disabilities

Slide 19

Slide 19 text

4. Cognitive disabilities Examples: - Autism - Attention deficit disorder (ADD) - Anxiety disorder - Dyslexia: difficulty in reading - Dyscalculia: difficulty in understanding number-related concepts - etc

Slide 20

Slide 20 text

4. Cognitive disabilities In regards to dyslexia, sans-serif fonts are recommended and fonts that have an unique shape for each letter. e.g.: Arial, Comic Sans*, Verdana, Century Gothic A font created with dyslexia in mind: https://www.dyslexiefont.com/en/typeface/ *Comic Sans is a great font choice for countering dyslexia

Slide 21

Slide 21 text

4. Cognitive disabilities Not all disabilities can be overcome purely from the UI. We need to understand the difficulties our users are facing and only then, together with the UX, we can probably do something about it. Dark Patterns: tricks used in websites and apps that make you buy or sign up for things you didn’t mean to. Darkpatterns.org About users with social disorders using the web: https://developer.paciellogroup.com/blog/2018/08/a-web-of-anxiety-accessibility-for-people-with-anxiety-and-panic-disorders-part-1/

Slide 22

Slide 22 text

Disabilities to account for: 1. Blindness and vision impairment 2. Deaf and hard of hearing 3. Physical disabilities 4. Cognitive disabilities

Slide 23

Slide 23 text

Laws and Regulations Starting with January 2010, all new EUROPA websites must be compliant with the Web Content Accessibility Guidelines 2.0, level AA. http://ec.europa.eu/ipg/standards/accessibility/index_en.htm In 2017, WCAG 2.0 AA compliance has been imposed in the U.S. as well. https://siteimprove.com/en-us/blog/no-more-excuses-there-is-now-a-us-deadline-for-beco ming-accessible/ WCAG 2.0 standard: https://www.w3.org/TR/WCAG20/

Slide 24

Slide 24 text

Laws and Regulations Here’s a glimpse of WCAG 2.0 AA rules: ● Links Links must have a context. The text within the link must be discernible. ● Media Captions are provided for all live audio content in synchronized media. ● etc

Slide 25

Slide 25 text

Tools and Technologies for Accessibility 1. Semantic markup 2. WAI-ARIA 3. Accessibility DOM Tree 4. Screen Readers 5. The A11Y project

Slide 26

Slide 26 text

Semantic Markup Each HTML tag has been created with a purpose. Developers have enough flexibility to use every tag as any tag, filling the behavior with CSS and JS. By using the markup as intended, it gives the document meaning (or semantics).

Slide 31

Slide 31 text

Demo CV HTML 4 http://127.0.0.1:5500/pages/demo1.html

Slide 32

Slide 32 text

HTML 5 tags

Slide 33

Slide 33 text

Demo CV HTML 5 http://127.0.0.1:5500/pages/demo2.html

Slide 34

Slide 34 text

Tools and Technologies for Accessibility 1. Semantic markup 2. WAI-ARIA 3. Accessibility DOM Tree 4. Screen Readers 5. The A11Y project

Slide 35

Slide 35 text

WAI-ARIA Web Accessibility Initiative - Accessible Rich Internet Applications It is a technical specification created by the World Web Consortium (W3C) on increasing accessibility of the web. https://w3c.github.io/aria/ With HTML, CSS and JS we can recreate the behaviour of any existing tag. With WAI-ARIA, we can fill the accessibility gaps.

Slide 36

Slide 36 text

WAI-ARIA Roles: defines what an element is or does e.g.: role=”navigation” The HTML5 tag is a Landmark with the ARIA role of navigation built-in. We can manually add the ARIA landmark role=”navigation” to any html tag. Properties: used for adding extra meaning or semantics to elements e.g.: aria-required=”true” States: special properties that define the current condition of elements e.g.: aria-disabled=”true”

Slide 37

Slide 37 text

WAI-ARIA Start building an UI with native HTML elements (they have built in semantics and behavior). Continue with adding ARIA roles, states and properties to the elements lacking the desired accessibility. List of all ARIA landmark roles: https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html

Slide 38

Slide 38 text

WAI-ARIA Basic usage example of ARIA landmark roles: https://www.html5accessibility.com/tests/roles-land.html

Slide 39

Slide 39 text

Demo Buttons http://127.0.0.1:5500/pages/demo3.html

Slide 40

Slide 40 text

Tools and Technologies for Accessibility 1. Semantic markup 2. WAI-ARIA 3. Accessibility DOM Tree 4. Screen Readers 5. The A11Y project

Slide 41

Slide 41 text

Tools: Accessibility DOM Tree We can think of the Accessibility Tree as an API describing the basic page structure with less information and fewer nodes. e.g.: example of an Accessibility DOM Tree for a basic form

Slide 42

Slide 42 text

Google Chrome Canary Accessibility Tab

Slide 43

Slide 43 text

Mozilla Firefox Developer Edition Accessibility Tab

Slide 44

Slide 44 text

Tools and Technologies for Accessibility 1. Semantic markup 2. WAI-ARIA 3. Accessibility DOM Tree 4. Screen Readers 5. The A11Y project

Slide 45

Slide 45 text

Screen Readers A screen reader is a form of assistive technology. It facilitates user interaction with content. It relies on a user agent to retrieve and render content.

Slide 46

Slide 46 text

Screen Readers Available solutions: ○ VoX (browser extension) ○ Voice Over (MacOS, iOS) ○ NVDA (Windows) ○ ORCA (Linux) ○ Dragon (3rd party) ○ JAWS (3rd party) ○ TalkBack Android

Slide 47

Slide 47 text

Screen Readers Screen Readers react to ALL CAPS and CSS text-transform: uppercase. There are two specs that we can use to customize the way the screen reader reads: 1. CSS Speech Module (limited browser support) https://www.w3.org/TR/2018/NOTE-css3-speech-20180605/ The Speech Module is the successor of Aural Style Sheets (deprecated). https://developer.mozilla.org/en-US/docs/Web/CSS/Aural 2. Web Speech API This specification defined a JavaScript API that enables integrating speech recognition and synthesis into web pages. https://w3c.github.io/speech-api/speechapi.html

Slide 48

Slide 48 text

Screen Readers Both CSS Speech Module and Web Speech API use Text To Speech (TTS). A Text To Speech system converts normal language text into speech. TTS engines are built in most platforms. Voice assistants like Alexa or Google Assistant use the platform’s TTS most of the times. But they can also use a bundled TTS alternative (for better language support or a wider choice of voices). https://tink.uk/using-the-web-speech-api-to-simulate-css-speech-support/

Slide 49

Slide 49 text

Tools and Technologies for Accessibility 1. Semantic markup 2. WAI-ARIA 3. Accessibility DOM Tree 4. Screen Readers 5. The A11Y project

Slide 50

Slide 50 text

The A11Y Project The A11Y project’s main goal is to facilitate accessibility implementation on the web. It is an open-source initiative, with the objective of promoting accessibility. It provides an up-to-date collection of resources and how-to examples and it also tracks events on the topic. The term ‘A11Y’ stands for AccessibilitY as a numeronym. 11 https://a11yproject.com/

Slide 51

Slide 51 text

Tools and Technologies for Accessibility 1. Semantic markup 2. WAI-ARIA 3. Accessibility DOM Tree 4. Screen Readers 5. The A11Y project

Slide 52

Slide 52 text

Accessible Web Components http://127.0.0.1:5500/pages/demo4.html

Slide 53

Slide 53 text

Thank you! Questions ?

Slide 54

Slide 54 text

References ● Demo: https://github.com/razvan-rosu/demo-we b-accessibility ● WCAG 2.0: https://www.w3.org/TR/WCAG20/ ● Semantic markup: https://html.com/semantic-markup/ ● WAI-ARIA: https://w3c.github.io/aria/ ● The A11Y Project: https://a11yproject.com/