Web Accessibility Bullets
Accessibility is often ignored when developing applications. However, most of us will end up needing some type of help, in terms of accessibility. Further, one out of six has a limitation or disability where A11Y functionality will help them use these applications, on web, desktop, or even on terminal shell of a headless server computer. Let me outline Web Accessibility - what, why, how.
Limitations, disabilites, diversity, pluralities
So, some people may be blind, deaf? A complete disability. But then even a partial limitation to eyesight might limit the use of many web apps.
Unless accessibility is considered, planned and designed, for.
Further, every single one of us will develop limitations with aging. You too.
Web and client devices: technology
With disabilities (or limitations) one needs further solutions. Perhaps eyeglasses? Or a screenreader to read the text on the screen?
Screenreader is an assistive technology solution.
Browser font-size change implies adaptive strategy to access the content.
Many ways to use tech
And the individuals use these technologies and strategies in their own ways! Some might use screenreader for convinience, just like some use eyeglasses as style accessory.
Just as subtitles, closed captioning, can be used to understand unknown language, or to learn it. While some might use subtitles because of hearing loss.
Disabilities, you mean physical limitations?
What do you even mean with this? Do you know? I mean people who cannot use the common technologies. For example, using a mouse or a display screen might be impossible to some.
From Web app perspective, the design and code must take this into account. And W3 web standards do offer some solutions, clearly.
Keyboard accessibility
This seems to come up first, and seems obvious. But in reality the typical web-page is not made to use keyboard navigation.
Focus or lack of focus
Web pages have a focus state that points to one element at once. To have a web-page offer keyboard nav, this focus must be available for all the relevant elements. That is, main landmarks of the page. Typically we approach this with visual elements,
Another problematic scenario are hover-based elements and their dynamics. For example, a tooltip may not be visible when using keyboard-navigation.
Define focus, focus style and focus order
The :focus CSS-pseudo-class is used to select the elements for styling. See: https://developer.mozilla.org/en-US/docs/Web/CSS/:focus
Default focus runs with links, form controls, image maps. Custom elements and navigation may not offer correct focus, behavior, order or target-wise. The css-styles should be set to indicate focus for important elements, such as links.
Focus order
Typical keyboard-only user will browse the page with <Tab>-key. The focus will jump sequentially, in order, but unless this order is clearly defined in the HTML, a11Y-fail may occur.
The focus jump target must follow a logical order. And if the page is updated, for example with a modal dialog, the focus should follow logically, or keyboard-navigators will be lost as the focus-box is in the wrong place.
Skip links
A page or its navigation menu may be a long journey for keyboard navigator. After all, the tab-key jumps over every focus-item. Adding a anchor-link that jumps over menus into content may improve the UX, and the a11Y.
Element size and position
Sometimes element size or movement on screen can pose challenges for non-mouse users. A small-font link-list is hard for everyone to use on touch-screen, leading to tap of inccorrect links. Limitations in coordination may lead to the same problem.
One example of such is on-screen keyboard. Small buttons in tight formation leads to mistyping even for people without physical disabilities, requiring re-tries even from acutely-eyed.
Some suggest voice search for form entries, and replacing free-text input with dropdown-menus, radio buttons or checkboxes, and including predictive text or pre-populating form data if possible.
I would just avoid small elements, myself. Some new designers think tiny is neat. It's not.
Assistive Input Devices
Most people use the keyboard and mouse, touch, voice, today even gestures, to control their devices. People with CNS related disease may not be able to do so. So alternatives like eye-trackers, slow-moving joysticks, camera controllers, button switches, even sip-and-puff switches are used, instead.
Some even consider these assistive technologies useful for people with cognitive or learning challenges.
Speech recognition and voice input
Given coordination or other limitations, spoken language can be used to control ones devices, and consume web content. Even arthritis may limit the use of keyboard, just like missing limbs or paralysis. Text input and web search may be the most common use-cases.
Typically voice input is similar to dictating messages: in addition to text-content, punctuation and commands must be used. This may bring some complexity. This as well as configuring voice input software, although voice assistants are somewhat common in contemporary operating systems.
Challenges similar to screen reader or keyboard navigation also occur with speech input. A link might be an image, button might have unclear name. Just like if keyboard nav doesn't offer focus for a button, or if button focus order is different from apparent element sequence. Or if focus is simply not visible.
Some accessibility tools and browser offer a way to number links and elements, so that they can be selected via voice input. Theres also the visual grid selector that can be controlled via voice to select clickable items.
Keyshortcut and voice control collisions
Another interesting scenario is where app developers have designed the app with single key shortcuts. These keyshortcuts can cause multiple things to occur with voice-input: one phrase can trigger multiple actions.
So the best practice here is to allow users to customize the keyboard shortcuts.
Vision disability
With vision disability, one must use a screen reader, a program that reads out the content on the screen.
Alternative content
A screenreader cannot read the parts of the content that is not in textual format. Therefore, alternative text-content is needed for images, buttons, controls and video. For example, images that are important for content or act as links should have alt-attribute that contains descriptive text.
Alternate text is essentially a transcript. Alternative text content quality should be considered. Long and complext text may confuse the user or slow down navigation.
Keyboard accessibility
Blind users must use the keyboard to navigate. The same limitations and challenges as sighted users using keyboard navigation face the vision impaired users. Poorly defined structure, focus items and order can ruin the experience.
Structure
Well-structured markup is important for both users and screenreaders to be able to make sens of the content. Just as sighted users look at headings and paragraphs, structure enables screen reader software to enable browsing and jumping within content. Same as keyboard navigation requires proper focus structure.
Screen readers
Screen reader will read out the content on the screen. In a web-app, screen reader may be able to also describe the state, type or role and the context or name of an element. This requires the web content is correctly coded.
Screen readers enable users also to navigate content like keyboard navigation. As mentioned above, structure of the document makes this possible, and problematic unless properly structured.
Common screen readers include Windows Jaws, NVDA and Narrator, Apple-devices VoiceOver and Android devices TalkBack. Many operating systems include their own screen reader. Many linux OS installers also come with a screen reader.
Braille readers (haptic interface peripheral) can be used along with screen reader software. Today there are bluetooth-enabled braille displays that can connect to mobile devices.
Individuals with cognitive or learning disabilities sometimes use screenreaders with web content. It can help with focus and concentration and comprehension of content.
Mobile screen readers
Gestures enable users to consume content on mobile devices. These gestures include tap or touch, swipes and rotating rotor.
The specific gestures used by screenreaders vary, and there is no universal standard.
Content navigation involves jumping headers, focus numbers, form elements and buttons.
Low vision
Limited vision imposes certain challenges related to content consumption. Fancy design often involves small fonts, poor font-type, contrast, and makes life more difficult, when the designer thought they were being unique. Relying on graphical elements alone leaves keyboard navigators and screen reader users guessing.
Fonts
Small fonts are a common problem. Font-size doesn't have to be huge to cater to most people, but often designers confuse small font size with stylish design. Its not, its a noobie mistake!
For web content, text resizing should be considered, and it can help this problem. Browsers come with both content resizing.
Colors and contrast
Traditionally, color and graphical elements were used for layouts in print-media. Some of this has carried over to web media. However, proper contrast and color choice is challenging.
Poor color contrast will affect people with visual and cognitive limitations, just the same as it will affect all people under bright light such as noon sunlight. Think "strava app with orange text on white, outdoors on a sunny day, on a smartphone."
Therefore its important to consider this for ordinary people just as it is for people with low vision - which will happen to all of us as we age.
Color is not perceived identically by all
Not everyone perceives colors the same. Color blindness, partial sight and age-related limitations to vision.
A screen reader or braille reader obviously doesn't communicate color. Quality web design accounts for these facts. A text alt should be used.
Moving content
Epilepsy, cognitive disabilities and vision limitations can make movement and animations distracting. Movement almost invariably captures attention, potentially distracting from the content. Different device screen sizes or content magnification can extrapolate these problems.
Dynamic elements that change and move pose similar problems. A showcase carousel may leave many users feeling disappointed or distracted, despite the flashy graphic design, just as banner ads often do. Controls are often small, or difficult to find. Even video autoplay can be poor design.
Popups, hover states and tooltips
Dynamic content like elements that are only visible during hover (mouseover or focus) can be difficult to access with a screen reader or even with screen magnification.
Care should be taken when implementing such elements.
Focus of attention
A person can only focus on one area of the content at once. Zooming, dynamic elements, hover popups and moving content will generate a lot of challenges, in respect to staying on track and not getting lost.
For example, form labels that are not near the form field, or a tooltip containing help on how to use the controls. If the content is poorly structured, the related contents can be lost.
If content that is relevant to the web page or app is not visible or nearby, it may become very difficult to follow. For example, if the magnified page menus occlude the page content, or the search filters take up so much fo the screen real estate that the search results are not visible.
Screen magnifiers
Most operating systems and browsers provide magnification that enlarges the content. It is used by people with some functional vision, with or without screen reader.
Typically a magnifier will follow mouse focus, where the mouse pointer is also magnified. Magnifiers may have other features such as text-smoothing, crosshairs-pointer, and color-inversion.
Dynamic content or unusual content placing will make navigation and content consumption difficult. Again, structure and layout should consider these factors.
Hearing disabilities
With popularity of video-based content on the web, many people with hearing loss experience challenges. There, video should have captions and transcription of the narration.
Subtitles even offer a chance to provide translated content.
Transcripts also contain description of the non-audio related content on the video.
Sign-language can help deaf users to consume content, where text may pose challenges if their first language is sign-language.
Subtitles
Subtitles, also known as closed captions, are on-screen text that transcribes what is spoken in-video. They are synced with the audio track.
In Finland, the captions are a common and familiar thing, and movies, series and documents are commonly consumed in foreign languages.
Even captions have the same challenges as other textual content: text size, font-type and contrast can make a difference between hard-to-follow, and enabling access,
Media player software and captions
As captions are a common thing in many cultures, most media players offer related functionality.
Subtitles-icon often appears near other player controls, depicted by speech bubble with lines of text, or "CC" icon. Subtitles on and off, or text-size controls are common.
Text and hearing disability
For people who are deaf, english or finnish may not be their first language, but sign-language. It is therefore not a given that text is easy to read.
Some of them may find it preferrable to follow a video with sign language, to captions.
Speech-related limitations
With the rise of voice-based services on the web, such as voice-based assistants, AI-chatbots and services such as Alexa, Google Home or Cortana, it is important to keep in mind that some individuals have speech-impediments or challenges.
Noisy environment or environment you are not expected to speak in are another clear challenge, just as mutism, effect of deafness on speech production, illness that affects voice, or neurological disease such as paralysis or dementia.
While speech impediment is no obstruction to consuming text or video content, the above factors imply that alternative access to voice-bases services may be an important consideration.
Assistants that provide quick access to you, may pose extraordinary challenges to some individuals. Voice-based search should be complemented with a text-based search option, as an example.
Further, accessibility challenges may occur on multiple faculties, and just voice-based interfaces may leave many users outside service.
Neurological and behavioral limitations
The plurality of challenges that face people with sensory or physical limitations can also touch individuals with autism, attention or learning deficits, for example.
Pages packed with content, complex user interface for an application, lot of text in small font-size, blinking or moving content. These all pose challenges in deficit of attention or cognition, just as they may be annoying to people with no such limitations.
Poorly formatted text in text-type and paragraphs and colors that make it hard to follow lines of text. Allowing users to adjust font-size, style and colors may help them consume content easier. Horizontally long text-lines, complex sentence structures (as in this document) and jargon are very common challenges.
Instead, long text should be divided with headings, subheadings, lists, images and graphs to help communicate the information of the text.
Icons and menu buttons pose similar challenges. Icons and image buttons can be ambiguous and have multiple interpretations. Providing a caption or a text label can help understand the meaning. "Close" text may help to convey the fact that a cross is for closing a window.
Movement and blinking invariably grab attention and can thus be incredibly annoying to people with neurological or congitive challenges. Just as they are distracting to people considered normal. Only use movement where grabbing attention is a requirement, not a choice. Movement should also be a temporary thing, or controls to pause animation should be available.
Customizing browsers
Customizing zoom (magnification), text-size and contrast are common ways to make content consumption more accessible.
Browser extensions such as the Tranquility Reader simplify content, and eliminate distractions. Sometimes mobile content version gives shorter text lines and less distracting layout.
Accessibility and realizing it
To make web content accessible, a whole culture of accessibility is needed. The people who create the content and author the tools need to be onboard. Standards and Recommendations are needed to help crete accessible tools and content.
As an outcome, both the technology platforms and the content on them can be accessible to people with limitations and disabilities.
Web technology and tools
While it is a complex topic, the web tech stack is relevant for providing accessible solutions and content to the public.
The demand and ability to make accessible web apps and content relies on browser frameworks, testing frameworks, W3.org metrics, and more. Processes and tools help author content meet these standards.
Aside from tools, user testing is essential to measure and ensure, that accessible content is available to us all.
Web standards
Most developers probably know what WCAG-guidelines are. Some even know of tools to measure whether WCAG level implementation for their webapp has been reached. Web Content Accessibility Guideline is a clear set of requirements, such as minimum text contrast ratio, for web content.
Similar guidelines exist for authoring tools and user agents (ATAG and UAAG, respectively).
Underneath, standards enforce web tech such as HTML and CSS are up to par and able to provide this platform.
WAI-ARIA is an initiative to bridge the guidelines and standards, the Web Accessibility Initiative Accessible Rich Internet Applications suite. In context of HTML, it helps to implement support for screen readers, and much more.
Ecosystem of people
Frameworks and standards are the tools, and enable the ecosystem participants to bring accessible web into fruition.
Product owners, developers, UX designers, content creators, QA and test engineers are all part of accessible content tools and creation.
Concert of accessiblity
Just as musical instruments alone won't make music, and people cannot play music without instruments, accessibility depends on all parts iterated above.
Tech platforms, authoring tools, browsers and smartphone OS, just as well as content authors, producers and designers must participate.
For this to happen, organizations and institutions should have accessibility strategy and policy that supports and implements accessible authoring.