Web Accessibility A brief guide 

Web Accessibility “Accessibility is the practice of making your websites usable by as many people as possible. We traditionally think of this as being about people with disabilities, but the practice of making sites accessible also benefits other groups such as those using mobile devices, or those with slow network connections.” (MDN web docs) ● People will visual impairments (blind users, low vision, colourblind, keyboard only access) ● People with hearing impairments (video only content) ● People with motor impairments (keyboard access) ● People with cognitive impairments (difficulty understanding or remembering) ● 2019, 10 million adults in the UK using the internet are registered disabled ● In some countries and markets (e.g. UK GOV websites) a certain accessibility standard is required by law, but not all. 

Web Accessibility ● Big field, so today a focus on users with visual impairments and motor impairments ● Experience browing the web with keyboard only access and/or screen readers instead of typical browsers. ● Screen Reader Example: https://www.youtube.com/watch?v=Q1gHxM1nP00 ● Good news is semantic HTML and good UX practice will not only help you with your SEO rankings, it will also help with accessibility ● For Javascript based complex experiences e.g non standard form elements, modals, paginated content there are additional additional solutions e.g. WAI-ARIA 

Web Accessibility: Design & UX ● Ensure good colour contrast between text and background, 4.5 : 1 ● Don’t use colour alone to make critical information understandable ● Meaningful content text in links, avoid `click here` as the content of any link, highlight `open in new tab` links ● How does the site work when zoomed in? ● The Trunk Test (Steve Krug) ○ What site is this? ○ What page am I on? ○ What are the major sections of this site? ○ What are my options at this level? ○ Where am I in the scheme of things? 

Web Accessibility: HTML + CSS ● Use HTML tags denoting page sections , , , , ● Use content tags

-

,

,

,
• . ● Label form elements using ● Use for interactive elements, keyboard accessible ● Use alt attribute to describe content that is relevant to user , but use alt=”” to denote design only images ● Don’t forget about focus states e.g. submenu triggered on hover ● Avoid display: none or visibility: hidden for hidden content that will be useful to users, there are other techniques. ● Tabindex is powerful when used correctly. 0 and -1 can help, positive values are not a good idea as they disrupt normal order https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML#Building_keyboa rd_accessibility_back_in 

Web Accessibility: UI & Javascript ● Javascript support in screen readers has improved dramatically over time. ● UI changes based on visual cues needs to be handled separately if the user only , e.g. media and controla, tooltips, modals opening, errors in form validation (inline or at the top) ● Modals: keeping context on where you were before you opened the modal (tabindex), keep user in the modal when navigation with the keyboard (hide everything outside of the modal). ● touchstart/end or focus/blur are more accessible triggers than mouse or hover events. So what if native semantics are not descriptive enough? 

Web Accessibility: Introducing WAI-ARIA A specification written by the W3C, defining a set of additional HTML attributes that can be applied to elements to provide additional semantics and improve accessibility wherever it is lacking. Three Main Parts: 1. Roles — These define what an element is or does. 2. Properties — These define properties of elements, which can be used to give them extra meaning or semantics. Properties are static. 3. States — Special properties that define the current conditions of elements, such as aria-disabled="true". States are dynamic. An important point about WAI-ARIA attributes is that they don't affect anything about the web page, except for the information exposed by the browser's accessibility APIs 

Web Accessibility: ARIA Roles 

Web Accessibility: ARIA Roles ● Landmark roles to aid navigation e.g role=”navigation”, role=”search”, role=”main”, role=”complementary” ● Document structure roles to help organise document structure, not normally interactive e.g. definition, figure, feed, math, directory, columnheader, cell, note, term ● Widget roles that are used for interactive ‘widgets’ or controls to help you signify semantics of a custom form control or UI element e.g. switch, toolbar, progressbar, tab, tabpanel, select, option,checkbox ● Live region roles are used for content that changes as user takes action e.g. alert, log, marquee, status, timer 

Web Accessibility: ARIA Properties ● The terms "states" and "properties" refer to similar features and look the same. The major difference is that “properties” tend to not change once the page is loaded, whereas “states” will. ● Example Properties ○ aria-label, aria-labelledby=”id” ○ aria-setsize, aria-posinset ○ aria-haspopup ○ aria-errormessage ○ aria-placeholder ○ aria-required, aria-readonly ○ aria-sort ○ aria-multiline, aria-multiselectable ○ aria-autocomplete 

Web Accessibility: ARIA States ● Example states: ○ aria-hidden, aria-disabled ○ aria-pressed, aria-selected ○ aria-expanded ○ aria-sort (value, asc, desc) ○ aria-valuemin, aria-valuemax ○ aria-current ● In reality, all these attributes are used in conjunction, and JS is used to modify the “state” properties as the user interacts with the page 

Web Accessibility: Example - Tabs 

Web Accessibility: Example - Tabs 

Web Accessibility: Example - Live Region 

Web Accessibility: Example - Modal ● Store last focused element when modal opens ● Use z-index to ensure dialog is the only focusable content while open ● Handle keyboard tab press within the tabindex values ● Handle Esc key presses and Close Button press, return focus to last focused element 

Web Accessibility: ARIA Support 

Web Accessibility: ARIA Support 

Takeaways ● Using semantic HTML, good UX practice and being aware of your product team’s demographics vs your users demographic can make a big difference ● WAI-ARIA is a powerful additional tool to make a more accessible user experience, if you can’t use native HTML tag and native semantics to achieve the same affect. ● Having a Javascript heavy app doesn't mean it can’t be accessible ● Making an interactive website fully accessible is possible and feasible, and even though it requires additional work and manual testing for the most part, the tooling is available 

Resources ● https://inclusive-components.design/ ● https://developer.mozilla.org/en-US/docs/Web/Accessibility ● https://www.ons.gov.uk/businessindustryandtrade/itandinternetindustry/bulletins/inter netusers/2019#recent-internet-use-by-disabled-adults-reaches-10-million-adults ● Jaws Screen Reader demo: https://www.youtube.com/watch?v=Q1gHxM1nP00 ● https://uxdesign.cc/accessibility-guidelines-for-a-ux-designer-c3ba775539be ● https://webaim.org/techniques/css/invisiblecontent/ ● https://www.w3.org/TR/using-aria/#rule1 ● https://a11yproject.com/patterns/ ● https://thoughtbot.com/blog/intro-to-accessibility