Huge Missing Part: Web Accessibility
Accessibility is the practice of making your websites usable by as many people as possible. Think of accessibility as treating everyone the same, and giving them equal opportunities, no matter what their abilities are. It is not right to exclude someone from a website because they have a visual impairment. We are all different, but we are all human, and therefore have the same human rights.
Accessibility is essential for developers and organizations that want to create high-quality websites and web tools, and not exclude people from using their products and services.
Accessibility has huge details when you dig into it. So it is not possible to cover every detail of it. Instead, I will try to mention about most important and mostly skipped parts.
Web accessibility is not an option, it is a necessity.
Semantic HTML
Semantic HTML refers to elements that provide structure and hierarchy, such as HTML5 landmark elements, headings, lists, forms, and interactive controls like buttons, links, and inputs. These elements come supplied with “implicit roles” baked-in from the browser and exposed in accessibility APIs, such as <main>, <nav>, <h1>, <button>, <ul>, and <fieldset>
Instead of using divs for every section of your HTML, it greatly impacts accessibility when you prefer the tags with implicit roles. For example, when a visually disabled person visits your page, each section will be announced by the assistive technology. So, when you use the tags with implicit roles, like nav, assistive technology will announce the section as “navigation”. Users will think that the navigation section will include all the links to navigate between pages and have an idea about the structure of your page.
Also, buttons, links, and forms are very important, especially for accessibility reasons. A user without access to their mouse, for example, might want to navigate over all of the controls (links and buttons) using their keyboard. <button> tags allow this behavior by default.
Developers should use these semantically meaningful HTML tags as much as possible and should not try to re-implement these tags with divs that have no semantic meaning at all.
Let me give you an example about trying to implement button elements with div by comparing them. Native <button> element will fire a click event from the Enter key, but a <div role=”button”> element will not. For custom controls built with divs, you will need to bind key-up and mouse-up events to ensure keyboard access works along with the mouse.
TIPS:
- Do not change native semantics, unless you really have to.
- Do not use role=”presentation” or aria-hidden=”true” on a focusable element. Using either of these on a focusable element will result in some users focusing on ‘nothing’. Applying aria-hidden to a parent of a visible interactive element will also result in the interactive element being hidden, so don’t do this either.
ARIA Attributes
Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities.
You can add meaning to your HTML tags by using aria attributes. Let’s say that you have a form and it includes some input boxes without labels. For the design of your app, you might not want to add labels to the form. But, assistive technology needs information about the input box to let the user know what is on the screen. the aria-label attribute might help you to define the purpose of your input boxes.
Let’s say you have a section, you want to give it a meaning about what kind of information that section holds. You can use the aria-label to define it:
Aria attributes are like ingredients or sessions of a cook. If you use them too much or unnecessarily, your app will be less accessible
If you can use a native HTML element or attribute with the semantics and behavior you require already built-in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
Html tags have their own purpose and meaning. For example, <table> component has its meaning when detected by assistive technology. Adding an aria attribute for a table can make it less or not accessible at all. Applying role=” presentation” to an <table> element removes all of that table’s semantics, and therefore elicited behaviors, in screen readers. It is as if it was constructed using semantically unassuming <div>s all along.
Aria attributes have a lot to cover. I suggest you deep-dive into this topic. It increase your web page’s accessibility when it used correctly
🔴 Live Regions
Today’s websites include alert boxes, notification bars, or some other parts that are rendered to the page by the result of an API call or a user action. Which means dynamically by javascript.
Assistive technologies help people to track what is on the page at that moment when the page loaded. But how about the elements rendered after an action?
Most of the time, developers do not even think about this or just ignore it. Just imagine that you visited a webpage and tried to log in with the wrong password and the developer did not add any alert box or any kind of feedback. You wouldn’t understand what is going on and most probably leave the page.
This can be the same for a visually disabled person who tries to log in with the wrong password and because the developer did not implement an alert box in a way to work with assistive technology, that person will not have any idea about what is going on. Assistive technology will not announce it.
Live regions solve this issue and for this kind of circumstances, it should be implemented carefully.
aria-live: The aria-live=POLITENESS_SETTING is used to set the priority with which screen reader should treat updates to live regions - the possible settings are: off, polite or assertive. The default setting is off. This attribute is by far the most important.
Normally, only aria-live="polite" is used. Any region that receives updates that are important for the user to receive, but not so rapid as annoying, should receive this attribute. The screen reader will speak changes whenever the user is idle.
aria-live="assertive" should only be used for time-sensitive/critical notifications that absolutely require the user's immediate attention. Generally, a change to an assertive live region will interrupt any announcement a screen reader is currently making. As such, it can be extremely annoying and disruptive and should only be used sparingly.
As aria-live="off" is the assumed default for elements, it should not be necessary to set this explicitly unless you're trying to suppress the announcement of elements that have an implicit live region role (such as role="alert").
aria-atomic: The aria-atomic=BOOLEAN is used to set whether or not the screen reader should always present the live region as a whole, even if only part of the region changes. The possible settings are: false or true. The default setting is false.
aria-relevant: The aria-relevant=[LIST_OF_CHANGES] is used to set what types of changes are relevant to a live region. The possible settings are one or more of: additions, removals, text, all. The default setting is: additions text.
The aria-relevant attribute controls which kinds of changes to the live region are considered worthy of readout. In this case, only newly added messages are really of interest so we set aria-relevant=”additions” on the parent element for the message stream.
Great implementation of aria-live for alert component with ReachUI:
🔴 Skip to Main Content
Adding a skip to main content or skip navigation link to your web pages greatly helps keyboard-only users. In most cases, these users won’t want to jump through all the navigation links before they begin to read the content. This is especially true when they have a look at more than one page on your site. Just imagine, without a skip navigation link, they have to go through the same navigation links on the homepage every time. It doesn’t seem like a particularly entertaining activity.
The page right below has this kind of implementation. To have a better idea about this topic please visit this web page and click the tab button. You will see a skip to the main content button to pass navigation.
SEO Impact
Google has made it clear: Websites that give users a better experience will be more visible on search results pages (SERPs) than websites with poor UX. UX and a11y are a topic that goes together.
Header tags define the hierarchical structure of a website page in much the same way we learned to outline our essays back in high school. There are six levels of header tags running from H1 to H6. For people that use screen readers, having structured headers tags are really important to understand the contents of the page. Also, having structured header tags have a great impact on SEO
Sitemaps help users and search engine crawlers navigate pages. Users with visual impairments often choose HTML sitemaps to navigate through a site. These pages give users an easy-to-navigate, big-picture overview of all site content. This is especially helpful for websites with important interior pages that are not accessible via primary navigation. That's why sitemaps are not only important for SEO, also for a11y.
To summarize, if you follow the rules of semantic UI implementations, you will end up having an improved SEO score and improved a11y.
There is an example of how a visually disabled person sees a web page. I strongly suggest you watch this video and have a better understanding of web accessibility.
