From dcee01c8bf9de5c3aa4ba71b0bbd60a5e0b194af Mon Sep 17 00:00:00 2001
From: Michail Yasonik
Pay close attention to the patterns of using{' '}
+ Though EUI strives to provide accessible components for apps to use,
+ accessibility cannot be created in a vacuum. Building experiences using
+ EUI components might be a strong start but how we stitch together those
+ components and the page structure overall plays a large role in the
+ accessibility of a page. The same way we fret about code quality, visual
+ design, and performance- accessibility is something that's never
+ “done” and is easiest to implement for the get-go rather
+ than retrofitted after the fact.
+
+ Additionally, not only do we have a responsibility to our users and
+ customers to not put up barriers from completing their tasks, we also
+ have legal obligations around the world to uphold. Both, governments
+ around the world and Elastic, strive to meet the success criteria laid
+ out by
+ For an intro to accessibility and how to plan for it in your projects,
+ watch this talk:
+
+ Two ways we can leverage semantics to make pages more accessible for
+ screen reader users is having solid headings and landmarks.
+
+ Headings are the simplest way to navigate pages for screen readers.
+ There are multiple ways to see all headings on a page, jump between
+ them, go to the next level, etc. Support for this is widespread and many
+ people are comfortable using it. A good heading hierarchy guarantees one{' '}
+
+ Landmarks are a newer (though, at this point also old by web years) way
+ to navigate pages and much more than just screen readers use landmarks
+ to manipulate the page. Many landmarks are mapped to HTML elements,
+ elements such as
+ Each page (what is rendered for a unique URL) should have a page title.
+ This page title should be unique to that page, and should accurately
+ reflect what that page does.
+
+ Use this format:
+ Note that the unique page title is first. This is because it is the most
+ important piece of information from a contextual perspective. Since a
+ user with a screen reader can interrupt the screen reader as they wish,
+ it introduces less fatigue when the unique page title is first, but
+ provides the additional guidance if it is desired.
+
+ This section copied from{' '}
+
+
+ A skip link is an
+ Skip links are particularly useful to sighted users who rely on a
+ keyboard or other assistive technology such as switches, voice commands,
+ or mouth sticks which can make navigating tab stop heavy content time
+ consuming and straining.
+
+ Accessible components always start with semantic markup but in complex
+ web apps that can often not be enough. To fill the gap between HTML
+ elements and complex widgets, ARIA and related attributes can be used to
+ include everyone
+ There are several aspects to focus management:
+ To let keyboard users know where focus is currently at, focus states are
+ an important part of design. As a base level, all browsers ship with
+ default focus states for all interactive elements. If you don't do
+ anything to touch it, you're already doing all right. EUI goes one
+ step further and replaces the default focus state with custom ones that
+ better match the Elastic brand and can provide better experiences such
+ as confirming color contrast.
+
+ Given that a keyboard user primarily can navigate pages in one direction
+ (either forward or backward), it's important to have an intuitive
+ focus order. Generally, focus order should follow the flow of the page
+ to keep it easy to follow. If you've made something interactive to
+ a mouse via JS, we can enable a tab stop there using{' '}
+
+ Navigating complex sites sometimes means your focus state will jump
+ around (e.g., skip links, modals, typeaheads, etc.). If we remove an
+ element that currently has focus without setting focus anywhere else,
+ users start over at the beginning of the page. Given the complexity of
+ average pages today, this can be a harrowing ordeal, especially if it
+ happens frequently. Unless theres a strong reason to do otherwise, focus
+ state should always try to return to where it was previously if the
+ currently focused element is to disappear (e.g., closing a modal might
+ mean your focus is on a close button; when the modal closes, we should
+ put focus back on the button which opened the modal).
+
+ This is the name of an HTML element as it's exposed to assistive
+ technology. This accessible name can then be read by a screen reader or
+ can be targeted for an action.
+
+ For a lot of content, the accessible name comes from the element's
+ inner text, such as:
+
+ For some content, special attributes might be required to give an
+ element an accessible name. For images, we use
+ Some HTML elements have associated elements which provide accessible
+ names for them. Form elements are the most ubiquitous example, a
+ checkbox won't have a name by itself but, associated with a label,
+ assistive technologies can make the connection:
+
+ Only having an accessible name, however, doesn't always lead to the
+ best UX. Take a list of available fields that someone might want to add
+ to their filter (say, on the a discovery page of a popular open source
+ project):
+
+ Here, a user will hear and see the same button 3 times. Though,
+ visually, they may clearly perform 3 different actions, if you are only
+ hearing all the buttons on a page, you have no idea what they do. There
+ are a few different patterns to use to help users differentiate between
+ repeated items:
+
+ Give lists an accessible name to improve their discoverability!
+
+ There are a lot of aspects to accessibility and covering all the bases
+ can be a lot to keep in mind. By relying on standards we can minimize
+ the amount of special casing we have to do in code but we should still
+ be cognizant of the many modalities users might use our products.
+
+ While low-vision users may use many assistive technologies in tandem,
+ for this section of the guides we'll primarily talk about zooming.
+ Two ways that users may zoom the page are increasing the base font-size
+ with browser tools or using a 3rd-party magnifier (sometimes a physical
+ magnifier) to better see the screen.
+
+
+ ZoomText is the most popular 3rd-party magnifier which will give users a
+ window to drag over content which will be magnified and can be read out
+ loud as well. Testing for the best experiences here is probably some of
+ the hardest because it's purely a visual-call on how close are
+ related pieces of information to each other that someone using this, or
+ similar, assistive tech will be able to see the whole control at once.
+
+ Blind and low-vision users often rely on tools such as screen readers
+ and braille readers to navigate the web. Their most basic function is to
+ read the page from top to bottom but a well-built page can be quick and
+ easy to navigate. Braille readers are a textual representation of what a
+ screen reader would be saying so we can focus on screen reader
+ compatibility.
+
+ The 3 most common, desktop, screen readers, and their most common
+ browser pairings are:
+ Mobile is a little simpler:Headings and Landmarks
+ '}
Further reading
+
+
+
+ Page titles
+ Further reading
+
+
+
+ Skip links
+ Further reading
+
+
+ Focus management
+
+
+ Further reading
+
+
+
+ Accessible names
+ Of note: Repeated calls to action
+ Available fields
+
+
`}
+ Available fields
+
+
`}Developer tip
+ My favorite fruit
+
+...
+
+
+...
+`}Further reading
+
+
+
+ Low-vision
+ Lov-vision/blind (screen readers)
+
+
+
+
+ Further reading
+
+
+
+
+ Practical examples
+
+
+ Blogs
+
+
+ Tooling
+
+
+ Spec docs
+
+
+