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.
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
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?
page sections <header>, <footer>, <aside>, <main>, <nav> • Use content tags <h1>-<h6>, <p>, <ul>, <li> . • Label form elements using <label for=”x”><input id=”x”> • Use <button> for interactive elements, keyboard accessible • Use <img> 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
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?
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
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
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
◦ 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
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
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
redroot
swamp09
d_endo
kakao
maruto
1024jp
10tera
satoshi256kbyte
memory1994
marokanatani
tsoshiro
ivargrimstad
tutinoko
skipperchong
keavy
brad_frost
kneath
aki_iinuma
quramy
tanoku
caitiem20
jonyablonski
zakiyama
soudai
