DEV Community: Alena Nik

✨ Access the limitless power of AI (and accessibility) ✨

Alena Nik — Fri, 28 Apr 2023 21:11:33 +0000

"When raising the accessibility topic, I often found some resistance because it was too difficult to accomplish, there were priorities, or because no one asked for it. In the end, no one wants to admit in a work environment that they don't even know how to start. And this affects me because we are a team, and we can learn together."

Introduction

As developers, designers, and inclusive writers, we are responsible for the accessibility of our products. This means more than just using semantic HTML, DOM order, and accessibility plugins without impacting cost, timeline, and other teams. We are responsible for shipping accessible products, and doing it quickly.

Accessibility means making sure that everyone, including people with disabilities, can use our products. AI (Artificial Intelligence) can help make things more accessible in many ways, such as using voice recognition, captioning and transcription, image and object recognition, predictive text, and personalized interfaces.

However, it is important to note that AI can also perpetuate existing biases and discrimination, including those towards people with disabilities.

Assuming that every company has knowledgeable people available to help with accessibility reviews is unrealistic. But can we apply basic accessibility knowledge to improve? The short answer is yes.

As I write this, I feel that it may be outdated tomorrow, but accessibility principles will never be. These principles aim to eliminate barriers that might prevent people with disabilities from accessing digital content or using digital interfaces.

As we know, AI has the potential to greatly improve accessibility for people:

Voice recognition: AI-powered voice recognition technologies can help people with visual, motor, or cognitive disabilities to interact with computers, smartphones, and other devices.
Captioning and transcription: AI-powered speech recognition and natural language processing technologies can be used to automatically generate captions and transcripts for videos and other media, making them accessible to people who are deaf or hard of hearing.
Image and object recognition: AI-powered image and object recognition technologies can help people with visual impairments to navigate their environment by describing images, recognizing objects, and identifying text.
Predictive text and auto-correction: AI-powered predictive text and auto-correction technologies can help people with motor disabilities to type more quickly and accurately.

Accessibility principles

Accessibility teams shouldn't become a bottleneck for the business, but they need to be prepared to spot issues faster than ever. A good way to evaluate the experiences we deliver is to evaluate them in the simplest way possible.

The industry-standard guidelines for web content accessibility are organized around four principles: Perceivable, Operable, Understandable, and Robust. These are standards that will not change tomorrow or in a year.

Understandable (AI-powered) 💫

Information and the operation of the user interface must be understandable, i.e.:

Text is readable and understandable.
Content appears and operates in predictable ways.
Users are helped to avoid and correct mistakes.

Notion recently came up with an AI solution as promised on Notion public website. Their solution offers summaries, writing improvements, corrections, and generates ideas for you. The advertised "Like a one-click photo editor, but for your words" concerns me a little.

For people with visual impairments, the reference to a "photo editor" may not be meaningful or relevant. Additionally, for people with cognitive or learning disabilities, the concept of a "one-click" tool may not be clear or easy to understand.

I would consider rephrasing it in a more descriptive and straightforward manner. For example, "Our tool helps you easily edit and improve your written content, just like a photo editor can enhance your pictures with one click." This way, the functionality is still being explained, but in a more inclusive way that everyone can understand.

Raycast AI also have the solution at Raycast website

"Magic at your fingertips. Unlock the power of AI on your Mac. Write smarter, code faster, and answer questions quicker. Get more done in less time!"

"Our AI-powered tool for Mac helps you write and code more efficiently, get quick answers to your questions, and save time" could work too. While it may be tempting to use metaphors or figurative language like "magic at your fingertips," we need to avoid making assumptions that AI is easy or magical. AI can be challenging for many people, and it's important to be clear and transparent about what users can expect from AI-powered tools.

Another example are Chat-like "Ask me anything" windows. Xata recently launched AI-build in feature to build applications with ChatGPT embedded in the database.

It's exciting amazing, but keeping in mind understandable principle of "content appears and operates in predictable ways" we can make it better. What will happen and who am I asking?

It's important to ensure that users understand what to expect when they interact with such features. One way to make it clear would be to provide prompts or suggestions on what type of questions users can ask or what information they can expect to receive from the AI.

Additionally, it's important to provide clear instructions on how to use the feature and what to do if the user experiences any difficulties. Testing with users with a range of abilities can also help identify any potential accessibility issues with such features.

Robust (AI-powered) 💫

Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. Robust content is compatible with different browsers and
assistive technologies.

There are several types of assistive technologies that may not be compatible with AI text generation experiences like ChatGPT.

Screen readers: people who are blind or have low vision may rely on screen readers to access digital content. However, screen readers may not be able to access the text generated by ChatGPT in real-time, as it is generated dynamically.
Braille displays: people who are blind or have low vision may also use braille displays to read digital content. Braille displays may not be compatible with the text generated by ChatGPT, as it may not be possible to convert the text into braille in real-time.
Speech recognition software: people with physical disabilities or those who have difficulty typing may use speech recognition software to interact with digital content. AI text generation experiences like ChatGPT may not be able to understand spoken input and generate text in response.
Switch access: people with physical disabilities may use switch access devices to interact with digital content. AI text generation experiences like ChatGPT may not be designed to accept input from switch access devices.

We need to consider these limitations and ensure that AI text generation experiences are as accessible as possible for people who rely on such technologies.

Operable (AI-powered) 💫

User interface components and navigation must also be operable. This means that functionality must be available from a keyboard, users have enough time to read and use the content, and content does not cause seizures or physical reactions. Additionally, users should be able to easily navigate, find content, and determine where they are. Different input modalities beyond the keyboard should also be considered.

I'm focusing on keyboard interaction and testing Notion AI solution with VoiceOVer. And had the following criteria handy:

As a sighted user using assistive technology, I wasn't able to understand that I've been in AI dialog at any moment. The focus was moved either to the image or empty input.

In fact, I had really hard time to make this screenshot for you: the keyboard option to pause.

2.2.1: Timing Adjustable (Sufficient)
2.2.2: Pause, Stop, Hide (Sufficient)

Testing with assistive technologies like VoiceOver or NVDA that we have handy can help ensure that the AI solution is keyboard accessible and adheres to the operable principles. It's important to consider the WCAG criteria to ensure that the AI solution is accessible to as many users as possible.

Wrap up

Personally, I'm very excited about how AI has evolved in the last few weeks.

I find it amazing that AI can assist people with cognitive disabilities such as dyslexia or ADHD by providing simplified language, summarising lengthy texts, and predicting and completing sentences to improve reading comprehension and writing. We can also implement these features when building or designing our own applications.

Moreover, by following simple accessibility principles, developers and designers can ensure that users can navigate and use the website or application effectively.

💫💫💫💫

Stay with me on twitter 👇

Alena Nikolaeva

@alenanik11

How many days until all* websites in the EU need to be accessible?: 794

Friendly reminder available on: online-accessibility-countdown.eu/?lang=en

#a11y

12:19 PM - 26 Apr 2023

Tell Me You Need Accessibility Without Telling Me

Alena Nik — Tue, 23 Aug 2022 18:34:20 +0000

Introduction

This is not a post about accessibility. This is a true story.

Hi, friend!

You know I wrote an article almost a year ago, saying that "Building accessible websites shows that you care about disabled people.". I've had another thought on that.

Vim.

Accessibility on steroids

"How many people with disabilities use my website?" - it's a common question that you can often hear or ask. You are building a metasearch, database, or management tool. Hands down, we hear this question a lot. But is it actually an accurate question?

Imagine that you, accessibility professional, just heard this question on a meeting. And your product is developer oriented and accessibility is not something that is prioritised.

Usually the conversation goes on, and on and you try to explain that it's not about our "target user" and it's not about a percentage of visually impaired users, and it's not about getting an accessibility overlay and we are done, and it's certainly not about just screen readers vs user agents.

I bet it sounds familiar.

Later you try to do your best to update internal policies to be more inclusive, you create documents on Notion and introduce bullet-proof practices (linters, testing, accessibility specs), try to get investment, conduct workshops and audit the product. And you, more certainly, succeed. After many conversations, many PR's, many Slack conversations "a tab is actually a checkbox?", removing modals, tooltips and disabled buttons and after many user testing sessions you get to something solid.

This is one scenario.

But let's get back to the initial question raised on a meeting: "How many people with disabilities use my website?"

Imagine if we pause here, and we don't gather the data about assistive technologies, we don't talk about temporal or permanent disability, and we don't talk about disability at all (at the moment).

Developer or User Experience

Imagine you are building a product for the user who prefers not to use the mouse. And hasn't been using one for some years. Why? Because, why not?

The question is now: "How many people use my website?"

Imagine you are building a technical, developer (or rather backend developer) oriented product. All of your efforts are on getting the best DX ever and no one yet raised a concert about accessibility, but then you realise that your "target" user may not have any disability at all. They just can't use the product and don't know why exactly. More over, the word accessibility or screen reader is not even in their heads, and they don't use typical accessibility short-cuts that we try so hard to support.

I'm talking about that user that you truly want as a long-term user and they will just silently drop and search for some similar product that has focus ring just because they navigate with the Tab key or Vim extension, like this one: Trydactyl: Vim, but in your browser extension

They don't like User Interfaces, they don't have JS enabled, they don't have complains, they just can't use developer oriented product thinking that something is not ok with their habits.

"It's not about making people adhere to the system, it's about making the system adhere to the habits of people."

Someone who likes plain old websites when the navigation was easy, we didn't have to wait for the site to load, we didn't have fancy smooth scroll. I can tell you more, these users can have JS disabled by default.

All they need is a focus outline and keyboard navigation to be perfect. They, most likely, don't know how to use screen reader and, actually, don't have to learn. Their choice is not to use the mouse. And this is your target user: a person who buys a car only with the keyboard, a person who shops for books, a person who buys flight tickets. How many people are not using a mouse just because they don't want to?

If your website does not have a good enough support for keyboard, which happens to be an accessibility requirement just like many others UX patterns, you would lose the users, and they would never complain.

Thinking out loud

"Can you tell me, what do you do if the website does not show you the focus outline?"

"Well, I just hit the Tab key until I find it, and then I quit. I go to another one. It's ok."

"Hey, and what about sites with animations and smooth scroll? You know, they are quite trendy."

"They are pretty, but you know... 8 years ago Why they keep making these?"

"I can never do grad and drop. Can you move my Trello card?"

"I used to use my keyboard to navigate websites more in the earlier days of the web."

There are tons of websites out there that would make their life easier, not harder, while offering something similar.

If we don't know where our product is going to end up, if it's 3G connection, if it's an old device, if it's not a mobile and not a desktop but something weird, and we implement defensive CSS by default, care about performance, and layout shifts without questioning. Then why do we question sometimes if the accessibility is needed if we don't know where our product is going to end up?

Focus on the essentials

So going back to the question on "how many people use my website?" and should you bring up the conversation about accessibility to the table?

Yes, and you would still need to do your best as an accessibility designer or engineer to get the product to the state where every user benefits from implemented accessibility features, but the conversation about whether your target user needs accessibility is much shorter.

We set high standards for accessibility and, personally, I don't think we should treat it as an extra work for advocacy groups, experts or something like a rabbit hole.

Can we possibly make it simple so our team is not stuck with reading specs all over again, feeling guilty about not passing audits or fail on "simple" things?

Full keyboard access, site consistency, be careful with huge sliders, parallax to name a few. These are users frustrations, all users frustrations.

Adrian Roselli 🗯

@aardrian

Weird how many of these map to WCAG Success Criteria.
twitter.com/vitalyf/status…

It is almost like you can improve usability by following the most baseline of accessibility standards.

13:04 PM - 20 Aug 2022

Vitaly Friedman 🇺🇦🏳️‍🌈 @vitalyf
🧵User frustrations in 2022. Just a few frustrating design patterns that we should be avoiding when designing today: – Tiny scrollable panes. – Tiny click targets. – Unexpected content shifts. – Mega-menus opening on hover. – Country selector dropdown. – Generic error messages. https://t.co/8IchNWQ9Xu

Tell me more

One of the ways I found to simplify the conversation about accessibility is (not bringing it up as a separate conversation) but to break it down to simple down to earth examples:

Keyboard support and focus visible https://www.w3.org/WAI/WCAG21/Understanding/focus-visible
Any people who like Vim in team? For sure!
Color contrast https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
Someone can't tell the difference between blue and turquoise? Yes, and it's a perfect use-case
Meaningful sequence https://www.w3.org/WAI/WCAG21/Understanding/meaningful-sequence.html
You don't like your JS to be enabled, I get it
Reflow https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
In case you use the website on your fridge's display or a modern toaster

I found it very beneficial to look for these examples in order to build trust and not to overwhelm people in my team with getting JAWS license, build match-media hook or ask for them to incorporate Cypress A11y checks into the CI ASAP.

Build up from something basic up to talking about motor difficulties, a special mouse, speech recognition software or on-screen keyboard emulator.

We can start by translating specs: "This Success Criterion helps anyone who relies on the keyboard to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time" to a simple language instead of copy-pasting European Accessibility Act to our Notion page and silently fix the violations on your own.

Make it a conversation about humans, humans that are in your team up until the point where the empathy and trust will grow to cover a variety of background, abilities and interests.

We never know what's normal

The takeaway that I'd like you to get is that there are many ways to plan accessibility strategy for a project, and many ways to bring it up to your team. But the reality is that real world needs are going beyond screen readers announcements and meeting accessibility criteria. Some users don't know they need accessibility, some users know they do.

Maybe, it's not a question about diversity and accessibility, it's not a question about "How many people with disabilities use my website?" or "This target audience is not that big, right?", it's not even a question. It's about making web better by default: taking care about our markup more than we care about selecting the best possible animation framework.

The experience that I got from my article from last year where I said that "what we can do is make sure that all of our users can have similar experiences" I still stand by this idea, but today I'm not looking for % of visually impaired users who rely on a screen reader to explain it to stakeholders.

I'm thinking about a backend developer who doesn't like the mouse. Then it's not about looking for a why making something accessible. Because, why not?

If you like this article, please, share it with your team and reach out to me on Twitter, whether you liked it or have suggestions 💚

Alena Nikolaeva 🦋

@alenanik11

Accessible markup patterns and components 🧱 🔗
aria-modal-dialog documentation is just lovely! Saving it for learning
github.com/scottaohara/ac…

18:01 PM - 07 Aug 2022

✨ Accessibility: a gentle introduction ✨

Alena Nik — Thu, 07 Oct 2021 20:32:33 +0000

Many times, I've tried to find a comprehensive, yet, not too detailed technical first-temps guide to accessibility for the team. So I decided to put together this one. For anyone who would want to step outside their daily coding tasks for a breath of fresh a11y air.
This article might be helpful for answer some common questions, leaving coding aside, such as:

Who is responsible for accessibility?

Who defines web accessibility?

Common principles

Legislation

First steps

The definition

At the most basic level, accessibility ensures that everyone, regardless of ability or disability, can access your website or application.

The definition is more nuanced than that, though. The Web is fundamentally designed to work for all people. However, poorly designed and inaccessible applications lead to broad-scale exclusion.

Who defines web accessibility?

👉 World Wide Web Consortium (W3C) - Web Content Accessibility Guidelines (WCAG)

💡 It’s important to note that the WCAG standards themselves are guidelines, not law. The W3C itself evaluates organisations based on these standards but doesn’t have the authority to enforce them.

The Web Content Accessibility Guidelines (WCAG) 2.1 is a comprehensive standard for web accessibility. It is also currently the basis for legislation on web accessibility in many parts of the world. In Europe, the guidelines are referenced in the standard EN 301 549 Accessibility requirements for ICT products and services, which is the basis for EU legislation on web accessibility.

Who is responsible for accessibility within the team?

To keep the commitment active, and most importantly, to translate it into action, all team members need to know how they should contribute in their own specific role. This is not limited to the roles working directly in web production, such as design, development, authoring, engineering, and testing practices.

Having said that accessibility is a team afford, it should be integrated into design process and product definition, from the start. Developers has to do out best to advocate for it and know the tools, but, luckily they are not on their own.

👉 Accessibility responsibility by roles:
Accessibility Responsibility Breakdown

Accessibility principles

👩🏻‍🚀 The industry-standard guidelines for web content accessibility are organised around four principles: Perceivable, Operable, Understandable, and Robust.

P
Information and user interface components must be presentable to users in ways they can perceive.
💡 Does your website work for people with low vision? Or in a grayscale mode?

O
User interface components and navigation must be operable.
💡 Functionality is available from a keyboard? Users can use different input modalities beyond the keyboard?

U
Information and the operation of the user interface must be understandable.
💡 Text is readable and understandable? Users are helped to avoid and correct mistakes?

R
Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. 💡Robust content is compatible with different browsers and
assistive technologies.

The guidelines include three levels of success criteria to be met when testing. These levels are denoted with A, AA, and AAA, with AAA being the highest level of conformance and A being the lowest, while still conforming.

🧑‍⚖️ Legislation (Europe)

Within the EU, the enforcement of the Web Accessibility Directive is currently the foremost factor driving demand for web accessibility knowledge and services in the public sector. With the upcoming European Accessibility Act, there will also be new legal imperatives on the private sector within the next few years.

The enforcement of the Web Accessibility Directive is based on monitoring, self-declaration, and the possibility for end-users to complain. If the organisation covered by the directive doesn’t fulfil its obligation, it can be fined.

European Accessibility Act

The European Accessibility Act (Directive (EU) 2019/882), is a directive that will enter into force in the member states by 2022. The act covers the private sector and focus on certain accessible products and services that have been identified as being most important for persons with disabilities.

European Union (2019). European Accessibility Act. Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services.

EUR-Lex - 32019L0882 - EN - EUR-Lex

The European standard for ICT accessibility: EN301549

The European standard “EN301549 v.2.1.2 Accessibility requirements for ICT products and services” acts as the presumed conformance to the minimum requirements of the Web Accessibility Directive.

Annex B covers the relationship between the functional performance statements and the technical requirements, and can be used to support the reader in understanding what
noncompliance may mean to different user groups.

When it comes to the technical requirements for web accessibility, the EN301549 is
referring to the international standard WCAG 2.1 AA.

There is a wide range of disabilities, but accessibility aims to make sure that people can use the web no matter their abilities. It is important to consider and design for different types of use cases, as listed in the EN301549.

Usage without vision
Usage with limited vision
Usage without perception of color
Usage without hearing
Usage with limited hearing
Usage without the vocal capability
Usage without manipulation or strength
Usage with limited reach
Minimise photosensitive seizure triggers
Usage with limited cognition

Very first steps as a developer

Status of your project 🥽
The very first recommendation you can investigate and try is to integrate a simple audit tool, such as axe for the DOM for potential accessibility issues, just to see where you are and how you feel. Manual testing can be hard at first, as you don't know what are you testing. It's an integration in the development environment and should be pretty straightforward, it gives helpful hints in the console while developing features.

If you’re setting up automated tests (and you probably should), you can even integrate axe with Cypress

👩🏻‍🚀 There is only so much that can be automated. Auditing the HTML and CSS for potential pitfalls is a good place to start, but ultimately it is not going to replace some careful manual testing.

Grab some checklists ✅

WCAG 2.1 quickref checklist 👉 http://www.w3.org/WAI/WCAG21/quickref/

Deque Web Accessibility Checklist for Developers 👉https://dequeuniversity.com/checklists/web

Deque Web Accessibility Checklist PDF for Developers 👉 https://media.dequeuniversity.com/public/en/docs/deque_web_accessibility_checklist.pdf

Deque Basic Web Accessibility Checklist for Designers 👉 https://dequeuniversity.com/assets/pdf/module-design/dq-designers-checklist.pdf

Wrapping up

Remember that this introduction is the starting point for an accessible design and web, not the endpoint.

Knowing the tools and being able to explain the importance of the work we do clearly makes a difference and if you just come to a11y community, I hope you stay 🙃

If you like this article and the information that I have put together, please, share it with your colleague and reach out to me on Twitter, whether you liked it or have suggestions 💚

Stay with me on twitter 👇
// Detect dark theme var iframe = document.getElementById('tweet-1351611328188862465-31'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1351611328188862465&theme=dark" }

✨ Inclusive components #2: the importance of headings

Alena Nik — Wed, 10 Mar 2021 19:54:56 +0000

Introduction

Heading elements (h1, h2, h3, etc.) help to break up the content of the page into related “chunks” of information. They are incredibly important for people who use assistive technology. If headings and HTML landmarks are used correctly, the user understands the meaning of a page or view and has a better experience.

Quick example

To illustrate the point, I want to show two examples:
Imagine that we have:

💡 A simple website, where visually we can distinguish the "blocks" of content, with headings, images and we clearly see the overall hierarchy.

We don't know yet whether the code behind it actually using h1, h2 and so on, but visually it's clear where the titles are and what is in front of us.

This is the same website with no heading structure and no hierarchy. For the users with assistive technology, it creates overall confusion since there is no way to know where to navigate. This is how it looks for the users that use a screen reader.
And here is how the website looks for them, when we - developers - code the correct document structure and respect heading order.

By the way, I'm taking the images example from A11ycasts#18 video with Rob Dondson, that I highly recommend watching 👉 A11ycasts episode on Youtube

"But I want to do it the right way. Where can I start?" 👩🏼‍💻

First, understand that users who use the keyboard and screen reader must be able to skip the content, navigate the web and get an equally good experience from the start.

Secondly, let's answer some of the questions with accessibility in mind:

Does your website makes sense if you view it after having turned off JS/CSS?
DOM order matches the visual order?
Can you navigate with the normal flow?
Do users have the ability to jump to any section of the document and get to the information quickly?

As you may know, screen reader users use heading to navigate through the page.

✨VoiceOver Keyboard Shortcuts✨

VO+H(Control+Option+H) to navigate

Control + Option + U to open rotor

Can you see how users can immediately benefit from the correct HTML tag and order?

Consider the example:

<h1>Title of the Page</h1>
<p>Here's a little bit of information before we get started</p> 
<h2>Hey you, heading 2</h2>
<p>Here's a little bit of info about the second heading</p> 
<h2>Here's another heading for testing purposes</h2>
<p>Here's a little bit of info about the second heading</p>

WCAG failures:

Heading-like text that isn’t marked up as headings (Level A)

❌
<p class="title">Introduction</p>
<div class="subtitle">Looks like a subtitle</div>

Illogical heading order (<h2> is not followed directly by an <h4>) (Level A)

❌
<h3>Bacon and mushroom risotto</h3>
<p>To cook a perfect risotto, it is essential to […] </p>
<h2>Instructions</h2>

❌
<h2 class="card-subheading">Subheading</h2>
<h4 class="card-heading">Heading</h4>

Nondescriptive headings (Level AA)

<h2>Recipe</h2>
<p>To cook a perfect risotto, it is essential to […] </p>
<h2>Recipe</h2>
<p>A coq au vin is a classic French stew in which […] </p>

Bad scenarios 🤨:

Not every issue counts as a WCAG failure, but they all potentially cause some confusion and pose potential barriers for people with disabilities. Such as:

A lack of headings (unless you’re striving for Level AAA)
Missing <h1>
More than one <h1> per page
Do not select heading levels based on their appearance (font-size). Select the appropriate heading rank in your hierarchy.
Using headings that don’t appropriately describe their related content does represent a failure of 2.4.6 Headings and Labels.
Headings should not be used as subheadings, subtitles, alternative titles, taglines, or slogans. In such cases, it is best to use a
tag.

Best practices (common sense)✅:

Headings are ranked <h1> through <h6>.
- <h1> representing the most important idea on the page
- sub-sections organized with <h2> level headings. Those sub-sections can themselves be divided with <h3> level headings, and so on.
Heading levels should increase by one h1 > h2 > h3 > h4 > h5 > h6

❌
<h1>Title</h1>
<h3>Some text that's not a heading, but we want "bigger" text</h3>

✅
<h1>Title</h1>
<h2>Chapter1</h2>
<h3>Some subsection</h3> 
<h2>Chapter2</h2>
<h3>Some subsection</h3>

The beginning of the main content should start with <h1>

<body>
  <header>logo - navigation</header>
  <main>
    <h1>Home page</h1>
  </main>
</body>

Most web pages should have only one <h1>
<h1> representing the most important idea on the page. At the same time, hero h1 does not necessarily represent the page, but it's just a slogan. #### What if the design doesn't have a heading?

Or it's not always can be present, but the page still should have the h1 heading to give the user context.

<body>
  <header>logo - navigation</header>
  <main>
    <h1 class="sr-only">Showcase page or another heading name</h1>
  </main>
</body>

Specs

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
Screen readers allow users to navigate by headings, so headings are an effective way to bypass blocks of content, as required by WCAG 2.4.1 (Level A)
Headings MUST be accurate and informative, as labels for the sections of text they describe. (Level AA)
Section headings are used to organize the content. (Level AAA)

Alternatives

If a scenario arises where you can’t make changes to existing elements’ hierarchy, there is an alternative method that you can use to provide semantics: using Accessible Rich Internet Applications (ARIA).

role="heading" can be placed on an element to assign it a role of heading.aria-level needs to be placed on the same element as role="heading" to assign the element’s heading level.

HTML5 outline

Sadly, heading algorithm was never really picked up by any browser or screen reader, and the HTML 5.2 draft advises against using it any further.

Real-world example

Here is a snippet from React library (linked in resources below) that implemented accessible <Heading/> and <Section/> components.

// Section

<section aria-labelledby={labelId} className={hidden ? "ric-hidden" : className} {...rest}>
  <Heading id={labelId} element={`h${level}`} className={noHeading ? "ric-hidden" : ""}>
    {label}
  </Heading>
  {props.children}
</section>

// Heading

const Heading = props => {
  const { element, className = "", hidden, ...rest } = props;

  const Element = element;

  return (
    <Element
      className={hidden ? `ric-hidden ${className}` : className}
      {...rest}
    />
  );
};

Resources 📂

A collection of inclusive components for React created with styled-components worth your attention if you want to quickly improve #a11y of the app 👩🏼‍💻

pbilyk / react-inclusive-components

Inclusive components for React, created with styled-components. Based on Heydon Pickering's book, Inclusive Components

react-inclusive-components

Inclusive components for React. Based on Heydon Pickering's book, Inclusive Components.

The library does not include React, it's just a collection of components to make the development of accessible apps easeir.

It has a minimum stylings that ensures that these elements are behaving properly and avoid different pitfalls (e.g. hiding an element from user but still making it accessible by the screen reader).

These components are not stateful and as abstract as possible to not interfere with any development that you are doing.

You can submit issues or Pull Requests at the GitHub repo.

Enjoy.

Usage

Button

Accessible button component. Can be of several types:

submit — Regular form submit button
button — Regular button that can handle various events
toggle — A toggle button for handling the 'on/off' state of various interface elements. Automatically adds aria-pressed attribute with the passed values.
toggle-dynamic — A toggle button…

View on GitHub

"Quick Reference" that I use a lot:

A customizable quick reference to Web Content Accessibility Guidelines (WCAG) 2 requirements

WCAG criteria

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

2.4.6 Headings and Labels: Headings and labels describe topic or purpose. (Level AA)

WCAG 2.1 through Level AA doesn’t require subheadings. Level AAA takes it up a level

2.4.10 Section Headings: Section headings are used to organize the content. (Level AAA)

Conclusion 💡

Guess how many heading I used in order to structure this post?

I kept getting back and forth in between "code" and preview in order to make my markdown match the visual structure. Can we do the same with our webs?

Remember:
✨The more you do it, the less of the effort it takes✨

If you like this article and the information that I have put together for you this time, please, share it with your colleague and reach out to me on Twitter, whether you liked it or have suggestions 💚

// Detect dark theme var iframe = document.getElementById('tweet-1363457207241740288-850'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1363457207241740288&theme=dark" }

✨ Inclusive components: making modals accessible 🧑‍🦯

Alena Nik — Tue, 19 Jan 2021 19:18:30 +0000

In order for us to help create a more accessible, equal society for everyone, change needs to happen. But for those changes to happen, we need to have conversations.
Holly - Award-winning disability blogger and writer

Introduction

As Holly is saying, 2021 seems like a good year to start having a conversation about accessibility, if you haven't started yet.

Working from home, shopping online, ordering food, doing anything online is often a challenge for someone who is blind or visually impaired and relies on a screen reader.

What we can do as front-end developers?
Make a small change, educate ourselves, have conversations, not to be afraid of sharing information.

I've started my accessibility journey this year and I invite you to join me. Today I'm sharing my notes on modals.

Definition

A modal dialog is a dialog that appears on top of the main content and moves the system into a special mode requiring user interaction.
This dialog disables the main content until the user explicitly interacts with the modal dialog.

Should I avoid modals all together? 🤨

Modals are evil and should be avoided it's a common misconception that existed for some time. The reasons might be:

Modals eat up a lot of space
If the content doesn't fit inside, the scrollbars might cause a problem on mobile screens
Any other reason
Often unaccessible

You can definitely discuss all of them with your designer, but let's break down the last one together.

Often, modals are a piece of UI that contains text or an image, or a form and buttons. Like alerts, modals disrupt the flow of what the user is doing, so we must help them to be able to open it, close and read through the content with the screen reader.

The problem

If the user navigates with the keyboard through our website, and the modal pops up, the user can't interact with the content (sign-in, say yes or even close it) because the keyboard focus is behind the modal. Pressing TAB or ESC won't work either. Very frustrating. 😣 If the user can't navigate, they will need sighted assistance.

What do the specs say? 🤓

First of all, "the rules" or "read the specs" sounds intimidating, I get that. No, really. But bear with me:

WCAG stands for Web Content Accessibility Guidelines. It's useful to developers as a guideline to make websites more accessible for disabled people. Those standards exist for us to use them, as any other resource.
Personally, I find myself reaching out to "Quick Reference":
A customizable quick reference to Web Content Accessibility Guidelines (WCAG) 2 requirements

This is what it says about Modal Dialog:

Initial focus placement.
Authors SHOULD provide a dialog label, which can be done with the aria-label or aria-labelledby attribute.
Keyboard interaction

➡️ Tab 
Moves focus to next focusable element inside the dialog.
When focus is on the last focusable element in the dialog, moves focus to the first focusable element in the dialog.
➡️ Shift + Tab 
Moves focus to previous focusable element inside the dialog.
When focus is on the first focusable element in the dialog, moves focus to the last focusable element in the dialog.
↩️ Escape   
Closes the dialog.

Focus and accessible descriptions are set based on the content of each dialog, usage of aria-describedby
When closed ❎, the focus is set on another element that provides logical work flow.

What Can I do? 🙂

There are many edge cases and it all depends on your particular modal dialog, but here are some quick-wins:

HTML

<main>
  ...content of my page...
  <button onClick="openDialog">Sign in</button>
</main>
<div role="dialog" 
     id="dialog"
     aria-modal="true"
     aria-labelledby="modalTitle"
     aria-describedby="modalDescription"
     tabindex="-1"
>    
  <h1 id='modalTitle'>Registration Form</h1>
  <button onClick="closeDialog">Close me</button>
</div>

Labeling

Give the modal an ARIA aria-describedby attribute which will be linked to the id of some visually hidden text which describes the modal’s function, and how to exit it.

The dialog has either:
A value set for the aria-labelledby property that refers to a visible dialog title.
A label specified by aria-label.
Optionally, the aria-describedby property is set on the element with the dialog role to indicate which element or elements in the dialog contain content that describes the primary purpose or message of the dialog.
WAI-ARIA Roles, States, and Properties

Shift focus when the modal is open

If the content is large enough that focusing on the first interactive element could cause the beginning of content to scroll out of view, it is advisable to add tabindex=-1.

Upon clicking the modal-activating button, all the main content should get an aria-hidden='true' attribute so that a screen reader will no longer read any of the content. Additionally, the modal should get an aria-hidden='false' and go from having {display: none;} to {display: block;}.

When a user clicks the ‘Open modal’ button then, we need to actively set their focus to the modal with JavaScript, and if they ever tab outside the modal, we need to set the focus back on the modal.

Tip: one of the tools that I use the most for focus debugging

✨ What has focus?
https://codepen.io/svinkle/pen/WgYRxq

When the dialog is open, pressing the ESC key should close it
What if the button is X? ❎

It is strongly recommended that the tab sequence of all dialogs include a visible element with role button that closes the dialog, such as a close icon or cancel button.

If the 'close' element is implemented as a button containing merely the letter 'x', you can do the following:

<div id="dialog">
   <button>Close</button>               
</div>

Exactly, just use the word "close". 'x' is commonly known multiplication sign, we don't want to confuse our users.

If you can't avoid it this is also another accessible option:

<button>
  <span aria-hidden="true">X</span>
  <span class="visually-hidden>Close</span>
</button>

In case of the icon, you need to make sure to use the high contrast close icon in the top corner for people people who have low vision:

<button id="open-toggle" aria-expanded="false" aria-controls="menu">
<svg aria-hidden="true" focusable="false">...</svg>
<span class="visually-hidden">Close</span></button>

“Hide” the svg with aria-hidden="true" focusable="false
icon itself (an svg image) should become irrelevant to screen reader with aria-hidden.

The svg also should have a focusable attribute set to false which prevents the icon itself from receiving focus in IE.

If a real <button> is not used, then your <div> will need:

tabindex="0" (to allow keyboard focus to move to it)
a click handler (for mouse users)
a keyboard handler (for keyboard users to use space and enter to select it)
a role="button" so a screen reader announces the proper semantics.

💁🏼‍♀️ To recap:

If we are dealing with a modal:

We want to manage the focus for full-sized modal so it’s not trapped behind.
Modal needs labeling role="dialog" aria-modal="true" to the modal window.
Ideally, close button would work with esc key.
We want to be able to close it and interact with the content.

Resources 📂

Github 👩🏼‍💻

andrewvasilchuk / vue-accessible-modal

Vue.js component for accessible modals

Chakra UI is one of my favorite references for accessibility in Vue components. They are doing an amazing job!

chakra-ui / chakra-ui-vue

⚡️ Build scalable and accessible Vue.js applications with ease.

Articles 📋

Creating An Accessible Modal Dialog
Modals (Dialog Windows)
Notifications

Specs 🧷

3.9 Dialog (Modal)

Conclusion 💡

Building accessible websites shows that you care about disabled people. It's a small change that makes difference.

How often could you hear someone say "I'm not sacrificing visuals for accessibility"? The good news is you don't have to. 😊 What we can do is make sure that all of our users can have similar experiences: to be able to find a button, have a dialog with the interface, close a modal or add items to the card.

I'm quoting Holly again and wish you good luck in making a small change for a better experience for all. Just give it a try tomorrow.

"The lack of accessibility leaves disabled people feeling frustrated, isolated, and forgotten. But when accessibility is considered, disabled people feel included and most importantly, we feel equal.

Accessibility should be at the heart ❤️ of everything you do. Whether it personally makes a difference to your life or not, accessibility should always be considered and made a priority."

If you like this article and the information that I have put together, please, share it with your colleague and reach out to me on Twitter, whether you liked it or have suggestions 💚

// Detect dark theme var iframe = document.getElementById('tweet-1349473220089573378-812'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1349473220089573378&theme=dark" }