<![CDATA[ Ilknur Eren - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ https://cdn.freecodecamp.org/universal/favicons/favicon.png <![CDATA[ Ilknur Eren - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ Eleventy Sun, 24 May 2026 22:23:57 +0000 60 <![CDATA[ How to Improve Web Accessibility with Landmarks - Explained with Examples ]]> https://www.freecodecamp.org/news/improve-web-accessibility-with-landmarks/ 68926eb93b7f491bf54aef85 Tue, 05 Aug 2025 20:51:05 +0000 If you’re reading this article on the freeCodeCamp publication, you should see some visual clues in different sections of the page. The header is at the top of the page. If you scroll all the way to the bottom of the page, you can see the footer section in grey background, which is clearly separated from the body with a white background.

freecCodeCamp, like other websites, visually separates the sections of the page to give the user clues so they can easily navigate between sections.

While sighted users have visual clues about the sections, those who use assistive technology like a screen reader, rely on landmarks to navigate through the page.

Simply put, landmarks are semantic regions in a web page that define the purpose of its sections. Landmarks allow assistive technologies to jump between major parts of the page, just like sighted users visually scan headings or menus.

Common HTML landmarks include:

  • <header> – Represents introductory content or a page header.

  • <nav> – Identifies navigation links.

  • <main> – Marks the main content area of the page.

  • <aside> – Contains complementary or related information.

  • <footer> – Represents page or section footer.

Table of contents

How to Navigate Landmarks in Any Browser

General Browser Support

Most screen readers support landmark navigation with shortcut keys. Here's a basic overview:

Screen ReaderOSShortcut
VoiceOvermacOSControl + Option + U (to open Rotor), then arrow keys to navigate
NVDAWindowsD to move to the next landmark
JAWSWindowsR to cycle through regions
NarratorWindowsCaps Lock + Right Arrow to move by landmark
ChromeVoxChrome OSSearch + Left/Right Arrow to move between landmarks

These shortcuts let users jump between regions—for example, from the <main> content directly to the <footer>—without tabbing through every interactive element.

How to Navigate Through Landmarks on a Mac Voice Over

  1. Turn on VoiceOver: You can easily turn VoiceOver by opening Finder and typing VoiceOver. Toggle VoiceOver on.

    Finder searching the word, "voiceOver" Underneath is a VoiceOver with a toggle to turn on. Underneath that is VoiceOver Utility

  2. Open rotor: Once you turned on voiceOver, press Control+Option+U on your keyboard. This will open the VoiceOver rotor. You can press right and left arrow to switch through different rotor items which include navigating with all headings, links and landmarks. Screenshot below is the accessibility rotor’s landmark item option on freeCodeCamp article. The article is divided up into navigation, search, main, article and footer elements.

Landmarks title followed up by navigation, search, main, article and footer

  1. Press down and up arrow to navigate through landmarks: Once you are on accessibility rotor’s landmark items, you can press down and up arrow to navigate to different sections of the page. If you want to go to the footer, press the down arrow until you reach footer and then press enter.

Why Landmarks Matter for Accessibility

1. Easier Navigation for Screen Reader Users

Screen readers provide shortcuts to navigate through landmarks. Without landmarks, users must tab through every single link or element, which is frustrating and time-consuming. In the freeCodeCamp article example, the user might want to skip to the footer in order to find and click on the donation link. Without landmarks, the user will need to tab through the entire article to reach the footer. This is time consuming and exhausting. Landmarks provide easy navigation to users that rely on screen readers.

2. Consistent Structure Across Pages

When every page uses the same landmark structure, users can predict where navigation menus, main content, and sidebars are located. This predictability reduces cognitive load. With organizing the page into sections, you can easily figure out where to go next.

3. Clear Context and Orientation

Landmarks communicate the role of content. For instance:

  • The main landmark signals: “This is the core content of the page.”

  • The aside landmark signals: “This is supplementary or related content.”

This helps users decide which areas to skip or focus on.

How to Use Landmarks

✅ Basic Landmark Structure

Here’s an example of a page using HTML5 landmarks:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Accessible Landmark Example</title>
</head>
<body>

  <header>
    <h1>Website Logo</h1>
    <nav>
      <ul>
        <li><a href="#home">Home</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <h2>Main Content Area</h2>
    <p>This is the primary content of the page.</p>
  </main>

  <aside>
    <h3>Related Links</h3>
    <ul>
      <li><a href="#resource1">Resource 1</a></li>
    </ul>
  </aside>

  <footer>
    <p>2025 Example Company</p>
  </footer>

</body>
</html>

The HTML is divided into 5 landmark sections which are header, navigation, main, aside and footer. If the screen reader wants to skip the header and go direct to the main content, they can do so by turning the accessibility rotor and clicking on the main landmark. Landmarks allow screen reader users to easily navigate through the page.

Here’s a breakdown of what each landmark is and how it's typically used:

<nav> – Navigation Section

Used for menus, site-wide links, or breadcrumbs.

<nav>
  <ul>
    <li><a href="/about">About</a></li>
    <li><a href="/courses">Courses</a></li>
  </ul>
</nav>

Real-world use: Jump straight to the navigation to find the “Contact” page without browsing through all the content.

<main> – Primary Page Content

Used once per page to wrap the most important content.

<main>
  <h1>Learn Accessibility</h1>
  <p>This article explains how to use landmarks...</p>
</main>

Real-world use: Skip past the header and sidebar to dive into the tutorial or article.

<aside> – Complementary Information

Used for sidebars, ads, related links, or pull quotes.

<aside>
  <h3>Related Tutorials</h3>
  <ul>
    <li><a href="/accessibility/forms">Accessible Forms</a></li>
  </ul>
</aside>

Real-world use: Users can skip the aside if they don’t want extra content, or jump to it for helpful resources.

<footer> – Page Footer

Used for closing content like copyright.

<footer>
  <p>&copy; 2025 FreeCodeCamp. All rights reserved.</p>
</footer>

Real-world use: Quickly navigate to support links, licensing info, or a newsletter sign-up.

<header> – Top-of-Page or Section Header

Used for introductory content, such as logos or search bars.

<header>
  <img src="logo.png" alt="Site Logo" />
  <form role="search">
    <input type="text" aria-label="Search site" />
  </form>
</header>

Real-world use: Quickly access the search input or return to the homepage.

Final Thoughts

Landmarks aren’t just an accessibility bonus—they’re a fundamental part of good UX. By implementing landmarks properly, you make your site easier to navigate for users with disabilities, comply with WCAG, and create a more predictable structure for everyone.

]]> <![CDATA[ How to Audit Android Accessibility with the Accessibility Scanner App ]]> https://www.freecodecamp.org/news/how-to-audit-android-accessibility-with-the-accessibility-scanner-app/ 6862d146cc277a35bb68ec20 Mon, 30 Jun 2025 18:02:46 +0000 The Web Content Accessibility Guidelines (WCAG 2.1 Level AA) is an internationally recognized standard for digital accessibility. Meeting these guidelines helps you make sure that your website is usable by people with visual, motor, hearing, and cognitive impairments.

Google’s Accessibility Scanner on Google Play is a free app that offers developers, designers, and product leaders the ability to audit their app to find accessibility issues. The app is designed to highlight accessibility issues that might not meet the WCAG 2.1 Level AA standards.

Once installed, the Accessibility Scanner allows you to take screenshots or video recordings of your app, then highlights areas that may not meet accessibility requirements, like small touch targets, low color contrast, or missing content labels.

Here’s what we’ll cover:

  1. How to Download and Enable the Accessibility Scanner

  2. How to Use the Accessibility Scanner

  3. Why Use the Accessibility Scanner?

How to Download and Enable the Accessibility Scanner

In five quick steps, you can download the Accessibility App and enable it on your Android device.

  1. Search “Accessibility Scanner” on Google Play Store and download it.

  2. Find the downloaded app on your device and open it.

  3. Turn on the Accessibility scanner by clicking on the “Turn on” button on the bottom right side of the page. This will take you to your Accessibility Settings.

  4. In the Accessibility Setting page, click on the Accessibility Scanner button. This will take you to the Accessibility Scanner Settings.

  5. Find Accessibility Scanner toggle and turn it on. (This will open a modal that asks if you allow “Accessibility Scanner” to have full control of your device, click Allow.

After step five, you will have a blue checkmark icon will appear on the right side of your screen (see image below). This floating icon gives you quick access to start scanning any screen for accessibility issues.

Facebook Log in Page with Accessibility Scanner toggle on the right with arrow pointing to it

How to Use the Accessibility Scanner

To scan or record your app to find accessibility issues, tap the blue checkmark icon. You’ll see a few options after clicking on the blue checkmark:

  • Record: Captures a short video of user interaction and generates a report of potential accessibility issues.

  • Snapshot: Takes a static screenshot and flags issues found on that screen.

  • Turn off: Turns the Accessibility Scanner off.

  • Collapse: Collapses the options to show the initial blue checkmark.

Facebook Log in Page with Accessibility Scanner toggle opened on the right with arrow pointing to it

You can choose between taking a single Snapshot or recording user flow using Record to evaluate multiple screens.

How to Use the Snapshot Feature

The snapshot button will take a snapshot of the page you are currently in and give you a result of accessibility issues that may be on the page. The accessibility issues will be highlighted in red boxes.

The image below is the result of taking a snapshot of the Facebook log in page. The accessibility scanner states that there are 10 accessibility suggestions on this page alone.

Facebook log in page with red boxes around several elements, highlighting accessibility issues.

You can click on the highlighted area in order to get more details of the potential accessibility issue. For example, you can click on the red box that is highlighting the “Mobile number or email” form that’s in the image above. Once you click on the highlighted area, you will get additional information.

The image below is the result of clicking on the “Mobile number or email” form element. Accessibility Scanner is highlighting errors it found on this email form.

The first suggestion it gives is to fix the item label, because the item may not have a label readable by screen readers. The second issue it highlights is the Touch Target and suggests that the target should be larger. The final suggestion is the Unexposed Text, possible text detected: Mobile number or email.

Snapshots allow us to take screenshots of our pages and highlight accessibility issues.

Email form field is selected from Accessibility Scanner. Scanner shows three areas to fix.

How to Use the Record Feature

If you select to record, the Accessibility Scanner will take snapshots at intervals as you go through your app’s pages. To end the recording, tap the blue pause button (which replaces the original checkmark during recording).

Once you stop recording, Accessibility Scanner will give you the several snapshots and highlighted errors. The image below is the result of recording the Facebook log in page in less than a minute.

While recording, I navigated to other pages within the app. The recording gave 5 snapshots of the pages I was going through. You can see the snapshots on top of the page. In the image below, I am on screen one of five,. I can click to the other snapshots underneath the words, “Screen 1 of 5” and see issues for different snapshots taken during my recording. Similar to the snapshot accessibility audit, you can click on the red boxes and get more information on the errors.

Facebook Log in Page with Accessibility Scanner highlighting elements with accessibility issues.

Why Use the Accessibility Scanner?

The Accessibility Scanner is a valuable tool for teams throughout the app development lifecycle. Engineers can use it early in the process to scan the app locally, identify accessibility issues, and resolve them before release. During the QA phase, designers and product managers can use the scanner to audit user interfaces and flag potential accessibility concerns. Even after an app is in production, all teams can continue to use the scanner to monitor and improve accessibility.

But it’s important to note that the Accessibility Scanner is just one part of an accessibility strategy – it’s not a complete replacement for manual testing or audits. And it won’t catch all types of accessibility barriers – especially those that require keyboard navigation, screen reader testing, or cognitive usability reviews. But it is a simple and effective starting point for improving accessibility in Android apps.

You should use it alongside other tools, such as Android’s TalkBack for screen reader testing. Most importantly, real-world feedback from people who use assistive technologies is essential to identifying usability barriers that automated tools may miss.

With just a few taps, Accessibility Scanner helps surface issues that might otherwise be missed. It’s a free, lightweight, and essential tool for anyone building inclusive mobile experiences.

Thanks for Reading!

You should now know how to get started using the Accessibility Scanner to check your apps’ accessibility and make sure they’re usable by everyone.

]]> <![CDATA[ Accessibility Resources for Developers ]]> https://www.freecodecamp.org/news/accessibilty-websites-for-developers/ 66d45f31f855545810e93458 Tue, 05 Sep 2023 22:49:13 +0000 Accessibility is never a "nice-to-have" requirement when it comes to developing websites and apps. It's a "must-have" that should be an integral part of your design and development process.

Ensuring good accessibility is a fundamental responsibility for developers. It can help their applications provide an equitable experience for all users.

But it can be easy to go down a rabbit hole when learning about accessibility best practices.

Fortunately, there are many resources available that teach you how to build accessible websites and apps. In this article, I'll discuss the three websites I frequently go to when I have questions about accessibility: W3C WCAG, WebAIM, and a11yprojects.

Let's look at each one and how you can use them to create more accessible projects.

W3C WCAG

First up, there's W3C WCAG. As stated in the Web Content Accessibility Guidelines (WCAG) website, WCAG provides, "strategies, standards, resources to make the Web accessible to people with disabilities".

The guidelines listed on this website provide comprehensive frameworks for developers to make the web pages universally accessible.

WCAG helps developers craft digital spaces that are usable, perceivable, operable, and robust.

One great section of W3C is the Easy Checks – A First Review of Web Accessibility. In this section, developers can easily learn accessibility rules when it comes to page titles, images, text, and interactions. Easy Checks section is a great place to start navigating W3C.

How to Use W3C WCAG:

  • Visit the W3C WCAG website and explore the guidelines and success criteria relevant to your project.

  • Study the techniques and documents for the technologies you're using.

  • Check the conformance requirements to set accessibility goals for your website or app.

To learn more about these standards and how to make a website accessible, you can come to W3C and study criteria needed to be considered accessible. W3C WCAG is one of the best websites to go to learn about accessibility rules.

WebAIM

On WebAIM's website, they state that they, "empower individuals and organizations to create and deliver accessible content".

WAVE is a accessibility evaluation tool. One tool WAVE offers is its Browser Extension. After downloading the WAVE browser extension, you can inspect your pages and log accessibility issues with the page. Then you can easily figure out how to fix these issues.

The WAVE extension is available on FireFox and Chrome and makes it so simple for your to recognize common accessibility issues. You can find instructions on how to download the WAVE extension on the WAVE's extensions tab.

After downloading the WAVE extension, you can go to your extensions and run it. Finding accessibility issues is as quick as clicking a button. For example, after downloading WAVE, I ran the extension on the New York Times homepage and was alerted to the accessibility issues the website had.

Image

Screenshot of New York Times Homepage with WAVE extension pointing accessibility errors

In the screenshot above, you can see The New York Times homepage with the WAVE extension running. On the left side of the screenshot, you can see WAVE's summary tab pointing out 1 accessibility issue in the homepage with 120 errors. This is WAVE's summary tab, which gives developers a overview of accessibility issues in the page.

Image

Screenshot of New York Times Homepage with WAVE extension pointing accessibility errors

WAVE goes in depth and explains the summary tab even further. Clicking on the details section of the extension lists the accessibility errors in greater details, which you can see in the screenshot above.

The one error that was in the summary page is explained further in the details section. WAVE points out that the accessibility error was a linked image missing alternative text. The 120+ warning are also listed in much more detail, which point out that there are 8 long alternative texts, 1 missing first level heading, 4 redundant link and much more.

The details tab is a great way to find out the accessibility issues your page might have and give you a starting point to fix the accessibility issues.

How to Use WebAIM:

  • Install the WAVE browser extension, then run it on your web pages to identify and address accessibility issues.

  • Explore WebAIM's website for additional resources, articles, and training materials.

a11yproject

a11yproject, pronounced "a-eleven-y-project" (with "11" representing the omitted letters in the word accessibility) "is a community-driven effort to make digital accessibility easier".

This website displays articles that are all about accessibility. The articles are written by developers and approved by the a11yproject team.

Some recent articles published on a11yprojects include, What is Semantic HTML? and The power of ChatGPT as a cognitive accessibility assistive technology for Traumatic Brain Injury survivors. There are many more interesting topics around accessibility as well.

a11yprojects are divided into different categories, which range from quick tips, background, myths, quick tests and so much more. Readers can go to a11yprojects and filter to a article category they want to see.

a11yproject articles are written by developers that are passionate about accessibility and have a lot of knowledge to share with others. You can go on a11yprojects website to read about latest news about accessibility. The website covers all aspects of accessibility, but mainly focuses on web accessibility.

How to Use a11yproject:

  • Visit the a11yproject website to read articles about accessibility best practices and the latest news in the field.

  • Engage with the accessibility community by participating in discussions and contributing your knowledge.

Conclusion

There are so many resources available online for developers to learn about the latest news on accessibility. There are also many communities of developers that are passionate about accessibility.

W3C WCAG, WebAIM and a11yprojects are just few online resources available for developers to conduct accessibility research. By going to these three websites, developers can learn the latest news on accessibility and study acceptable accessibility criteria.

]]> <![CDATA[ Web Accessibility – Common ARIA Mistakes to Avoid ]]> https://www.freecodecamp.org/news/web-accessibility-common-aria-mistakes-to-avoid/ 66d45f3b47a8245f78752a5a Wed, 11 Jan 2023 21:58:45 +0000 Accessible Rich Internet Applications – or ARIA – is a set of attributes and roles defined by the Web Accessibility Initiative. These make the web more accessible to people with disabilities.

ARIA is extremely important for building accessible web applications. But it's very easy to misuse ARIA and make the website less accessible.

This article will demonstrate five common ARIA mistakes and how to fix them.

Don't Use Unnecessary ARIA Labels

The first rule of ARIA is that you should not use ARIA unless you have to. HTML elements already have accessibility built in, and adding unnecessary ARIA labels can break accessibility.

For that reason, it's much better to use HTML elements, instead of constructing code with ARIA labels.

Example of misusing ARIA labels:

⛔ BAD: Below is a button element with aria-label:

<button aria-label="Send">Send</button>

✅ GOOD: Below is a button element:

<button>Send</button>

In the examples above, I am creating a button element. In the first code snippet, there is a aria-label with the label, “send”. HTML’s button element already has accessibility built into it. It is not necessary to add an aria-label so it's much better to remove the label.

The button element will read the text inside it already. We do not need to add the aria-label to describe it.

Takeaway: Don’t add unnecessary ARIA labels if you can use accessible HTML elements instead.

Don't Use the Wrong ARIA Attributes

There are pre-defined ARIA states and properties defined by the ARIA working group, which is part of World Wide Web Consortium.

Developers should use the states and properties available – you cannot create your own in your code. You can find the list of properties and states on W3's Website.

Example of using incorrect ARIA attributes:

⛔ BAD

<span aria-donotshow="true">Don’t show this</span>

✅ GOOD

<span aria-hidden="true">Don’t show this</span>

This means that a new property, like aria-donotshow, is not correct. aria-donotshow is not a property in the W3 website so you shouldn't use it.

Takeaway: Don’t create your own ARIA attributes. You can only use the ones defined by the ARIA working group.

Know When to Use aria-labelledby

Another common mistake is when developers use aria-label to describe content inside the DOM.

All interactive elements need an accessible name. If we want to add an accessible name to an element where the name needs some content from elsewhere in the DOM, we should use aria-labelledby. If there is no content that can be referred to to create an accessible name, then we can use aria-label.

Example of when to use aria-labelledby:

⛔ BAD

<div aria-label="Related Content">                
    <span>Related Content</span>        
</div>

✅ GOOD

<div aria-labelledby="nav-title">                
    <span id='nav-title'>Related Content</span>        
</div>

In the example above, the first code snippet uses aria-label and associates it with the text, “Related content”. But the span inside the text already has the correct content we want a screen reader to read.

Instead of using aria-label in this example, we should reference the span content by adding aria-labelledby that is associated with the id of the content we want to reference.

Takeaway: If you want to reference content from inside the DOM, use aria-labelledby with corresponding id.

Know When to Use aria-describedby

Sometimes, we need to give more information to an element. For example, we might want to tell the user that the button they will press will open a new tab.

This information is important because the user needs to know where they are when navigating websites.

For these types of scenarios, we can use aria-describedby to give additional information.

Example:

⛔ BAD

<button aria-label="Close" aria-label="Opens in a new tab">    
Show related        
</button>

✅ GOOD

<button aria-label="Close" aria-describedby="description">            Show related        
</button>        
<div id="description">Opens in a new tab</div>

In the first example above, what engineers expect the screen reader to announce is: “button, Show related, opens in a new tab”.

But the screen reader does not do that. Instead, it says,“button, opens in a new tab”. The screen reader does not read the content inside, because aria-label always overrides the text content of the HTML5 element it has been applied to.

The second code snipped shows the correct way to use aria-describedby. The screen reader will read, “button, Show related, opens in a new tab”.

That information tells the user that the button is to show related content and if they press that button, it will navigate them to another tab.

Takeaway: Use aria-describedby to add additional information to elements.

Don't Use ARIA Child Roles Without Parent Roles

There are some ARIA attributes that require a child/parent relationship. This means that you cannot use the ARIA child attribute without wrapping it around its parent ARIA attribute.

It’s easy to forget the child/parent relationship and build code that only uses the parent attribute without the child, or to build code that only uses child attribute without its parent.

If you forget the child/parent relationship, the code becomes more inaccessible, which defeats the purpose of ARIA.

Example:

⛔ BAD:

role="listbox" is a parent property. The ul list below does not have role=option which is its child property.

<div role="listbox">
    <ul>
        <li></li>
    </ul>
</div>

✅ GOOD:

role="listbox" is a parent property. The ul list below has role=option which is its child property.

<div role="listbox">
    <ul>
        <li option="option"></li>
    </ul>
</div>

In the code example above, the first code has a code snippet that has role=listbox which is a parent element. listbox needs children inside which is option. We cannot use listbox on its own to build accessible web sites.

Takeaway: Always use child/parent properties together.

Summary

ARIA is a set of attributes and roles defined by WAI to make the web more accessible to people with disabilities. Although it's necessary to create an accessible web, it is very easy to misuse ARIA and make websites less accessible instead.

Try to avoid these five most common ARIA mistakes:

  1. Don’t unnecessarily use aria-label. Built-in HTML semantics are always better.

  2. Don’t create your own aria attribute. Only use the ones defined by ARIA.

  3. Use aria-labelledby with an id when you have content that wraps divs and you want to group sections.

  4. Use aria-describedby when you have sections that need more descriptions.

  5. Do not use a child ARIA without a predefined parent ARIA.

ARIA was created to make websites more accessible to people with disabilities. If we avoid common mistakes, we will make sure our websites are accessible.

]]> <![CDATA[ Common Accessibility Errors and How To Fix Them ]]> https://www.freecodecamp.org/news/common-accessibility-errors-and-how-to-fix-them/ 66d45f35b6b7f664236cbddb Wed, 05 Jan 2022 21:15:24 +0000 The Web Content Accessibility Guidelines, or WCAG, defines how to make websites accessible for people with disabilities.

When we evaluate whether or not website is accessible, we look to see if software meets WCAG 2 standards.

Accessibility should not be an after thought, but rather a major part of the development process. Still, sadly these days there are many websites with accessibility errors.

WCAG's audit shows that many accessibility errors fall into just six areas/categories.

Most common types of WCAG 2 failures

WCAG Failure Type

% of home pages in February 2021

% of home pages in February 2020

% of home pages in February 2019

Low contrast text

86.4%

86.3%

85.3%

Missing alternative text for images

60.6%

66.0%

68.0%

Missing form input labels

54.4%

53.8%

52.8%

Empty links

51.3%

59.9%

58.1%

Missing document language

28.9%

28.0%

33.1%

Empty buttons

26.9%

28.7%

25.0%

96.7% of all errors detected fall into these six categories. Addressing just these few types of issues would significantly improve accessibility across the web. – WebAIM

If we tackle these six problems, we can make sure more websites are accessible for people who use various of assistive technologies.

Let's look at each of these common accessibility problems in more detail.

Update Low Contrast Text

In the code example above, we can see an example of one background/foreground color combo that meets WCAG standards and one that doesn't.

The low color contrast is the one with blue background and gray text. It's really hard to differentiate the background and foreground colors visually and the color combination does not meet WCAG standards. The foreground text blends into the background.

In the second example, the foreground is whitish color and it's easy to read the text. This color combination meets WCAG standard, and the text stands out on its own and is easy to read.

If the text color is hard to differentiate from the background it's in, we have a low contrast accessibility error. Over the last three years, by far the biggest accessibility error is low contrast text. More than 80% of websites have this accessibility error.

You can fix low contrast accessibility errors by simply auditing your website and changing the color of the text or the background. You can run a lighthouse test to see if color contrast is an issue on your website.

You can also check if the background/foreground color combo meets WCAG standards in the following link: https://webaim.org/resources/contrastchecker/.

Add Missing Alternative Text for Images

In 2021, it was reported that 60.6% of all home page images were missing alternative text.

It's important to add alternative text to images because you need to describe the content of the page to those who cannot see the content. Visually impaired users will use a screen reader, which will read the content of the page back to them.

For example, if we have an image of a basket of Belgium fries, we can add an alternative tag to that image with a simple alt attribute:

<img src="example.png" alt="basket of fries"/>

With one attribute, alt, we are able to make the image accessible for screen reader users. When a screen reader user tabs over to the image, it will indicate to them that they are focused on an image and that image is a "basket of fries".

If we didn't have an alt attribute, then the screen reader user wouldn't have known that the image they were focusing on was a basket of fries.

It's also important to note that an alt attribute is not enough for 100% accessible images. We also need to make sure that the alt tag is descriptive and lets the user know what the image looks like.

A bad example of an alt tag would be if it's not descriptive enough. Say we have the same image of the basket of fries and we add alt tag to the image like so:

<img src="example.png" alt="image"/>

In the example above, we would meet accessibility standards by adding the alt tag, but the alt tag is not helpful or descriptive enough for screen reader users. When a screen reader user focuses on this image, it will say, "image, image", which doesn't let the user know what this image is at all.

It's very important to add descriptive alternative tag to images on the page.

Add Missing Form Input Labels

About half of the websites were missing form input labels in 2021. A form label is an HTML element used in forms to describe what the the various fields in the form are for.

If you have any type of form on the page, whether it's checkbox, radio button or dropdown, you must have a <label> associated with this form.

A common error for missing form input is for search forms. Often search forms on a page usually have only a magnifying glass image to indicate to visual users that they can search with that form, but no label to indicate search. But if we don't add a label to this form, screen reader users will not know what the form is when they focus on it.

We can fix this accessibility error by adding a screen reader label.

HTML example:

<label for="searchLabel" class="sr-only">Search</label>
<input type="text" name="search" id="searchLabel>
<input type="submit" value="Search">

CSS example:

.sr-only{
   position:absolute;
   left:-10000px;
   top:auto;
   width:1px;
   height:1px;
   overflow:hidden;
}

In the example above, we added a label "Search" to the form with the help of CSS. When a user focuses on this particular form, the screen reader will read, "Search", to them. The class sr-only in this form will only make this element readable when on a screen reader.

Links are used to navigate the user to a new page or view. A link is focusable by keyboard and can be triggered by the enter key.

Similar to the missing form label error, another accessibility error is empty links. About half of the websites had empty links in 2021.

For example, if we use the Facebook logo to indicate to sighted users that the link is to go to Facebook, but we don't add any label for screen reader users, then we will get an empty link accessibility error.

If we don't add text for screen readers, then screen reader users will not know that they are focused on a Facebook logo.

A good example of adding a label to a link is below:

<a href="/facebook-page">
   <i aria-hidden="true"></i>
   <span class="sr-only">Facebook</span>
</a>

CSS correspondent:

.sr-only{
   position:absolute;
   left:-10000px;
   top:auto;
   width:1px;
   height:1px;
   overflow:hidden;
}

In the example above, we used a Facebook logo to indicate that this is a Facebook link. We also added "Facebook" text that will be read when users focus on it using a screen reader.

Add Missing Document Language

For the last three years, between 28% to 33% of homepages have been missing a document language on their page. This is one of the less common accessibility problems but it is still an accessibility error we should pay attention to and fix.

We can add the language to the HTML tag like so:

<html lang="en">
...
</html>

The example above indicates that the page is in English. We can use other codes to indicate other languages.

It's important to indicate the language of the page because screen readers use the document language to know how to pronounce the words. Document language is also good for SEO.

Fix Empty Buttons

Buttons are used to do things on a page, for example submitting a form or show/hide things. A button is focusable and can be triggered by the space key.

Similar to empty links, we need to make sure that buttons have text for screen readers to read when on focus.

The solution for fixing empty buttons is similar to fixing empty links, which is to make sure text label is present on buttons.

If an image is used inside button, we can add an alt tag to the image. This will ensure that when a user uses a screen reader, the image alt tag is read. Here's an example of how to do this below:

<button type="submit">
   <img src="/search.svg" alt="Search"/>
</button>

Similarly to an image, if you use an SVG inside a button, you can add a title inside the SVG. Here's an example of how to do this below:

<button type="submit">
   <svg id="search" role="img" aria-describedby="search" viewBox="0 0 16 16.9">
      <title id="search">Search</title>
      <path d="M14, 2L8690, 89.1,13,6.5G87"></path>
   </svg>
</button>

We need to make sure that buttons are not empty and that screen readers read what the button is to the user.

Conclusion

Accessibility should never be an afterthought, but rather a large part of the development process. Most accessibility errors come from six categories and if we fix them, we will make our websites more accessible to everyone.

Accessibility fixes should not be difficult and should only require basic HTML and CSS knowledge.

If we pay more attention to accessibility, we will open our websites to a wider audience and also make sure our code is good and meets standards. Accessibility not only helps everyone use websites but also improves the foundation of our code.

]]> <![CDATA[ Accessibility Best Practices for Mobile App Development ]]> https://www.freecodecamp.org/news/mobile-accessibility/ 66d45f3938f2dc3808b790a7 Thu, 30 Sep 2021 21:47:00 +0000 The United States Census Bureau estimates that more than 12% of the United States' population is living with a disability. Disabilities can include vision difficulties, hearing difficulties, mobility challenges, and much more.

And a person can become disabled at any stage of their life.

Since a significant portion of the population has one type of disability or another, it's important to develop tech that's accessible to everyone. This way we can all consume tech content and no one is left behind.

In this article, we'll cover some best accessibility practices and what you can do to make your mobile apps more accessible.

Add Helpful Descriptions to Each Element

The Center for Disease Control and Prevention's Vision Health Initiative states that,

In 2015, a total of 1.02 million people were blind, and approximately 3.22 million people in the United States had vision impairment (VI), as defined by the best-corrected visual acuity in the better-seeing eye.

In addition, 8.2 million people had VI due to uncorrected refractive error. By 2050, the numbers of these conditions are projected to double to approximately 2.01 million people who are blind, or having VI of 20/200 or worse, 6.95 million people with VI, and 16.4 million with VI due to uncorrected refractive error. (Varma 2015)

One useful accessibility tool for people with little to no vision is a voice over tool. This allows the user to listen to the content of the web page on their phone.

I would like to put you in the shoes of someone who might be using voice over on their phone.

Below is Facebook Marketplace's "reduced price" listings. Just listen to 22 seconds of this voiceover to hear how that section sounds to someone using the tool.

The voiceover says 'Reduced Price, button' to indicate to the user that this section is for reduced price items, and that there is a click action they can take in that particular focus.

Next, the focused element says, "Hide category, button" which again indicates that in this focused element, the user can take an action to hide the category.

Next, the "See all, button" gets focused. This indicates that they can take an action on this element to see all items in the category.

On the next focus, we hear, "No photo description available, button, image". What could this item be? We don't know at this point.

And for the next focused element, we hear the same thing, "No photo description available, button, image". Now two elements in this list have no content for the description.

The next focused element says, "Maybe an image of jewelry, button, image". The word "maybe" in front of the sentence indicates that the voiceover tool is not confident about what the element might be.

"Image of jewelry" is a broad description, especially if you are on a website to shop. Is it a necklace? Is it a ring? Is it an earring? Is it a set of jewelry? What material is it? What does it look like? How much is this jewelry to begin with?

And the last focused element says what we heard from the first two, "No photo description available, button, image".

This is how users with little to no vision have to navigate apps. There were four buttons here, none of them with a description. If you were using this app, which one would you click?

Now, I want to show you the video recording of the same page, which you can see below:

The first item that voiceover mentioned as "No photo description available, button, image" was actually an image of a vintage table from the 1960's and it's free.

The second item is a sticker that costs $3 that says, "I am always with you" with a red bird next to it.

The third item that only had a partial description ("Maybe an image of jewelry, button, image") is a pearl earring that is on sale for $8.

Lastly, the fourth item that said, "No photo description available, button, image" is a Pokeman card of Pikachu, that costs $9.50.

Did you expect this after the first audio clip? Probably not. If you didn't see the image or read the title, you would have no idea what's for sale on Facebook marketplace.

One way to fix this problem is to make sure that each element has an accessibilityLabel with the basic information you'd need to learn what it is without seeing it. The React Native docs tell you that,

"To use, set the accessibilityLabel property to a custom string on your View, Text or Touchable".

An accessibilityLabel is a simple but yet effective way to describe the element for screen reader users.

To show you how this would work, let's code a simpler example together.

For example, we could make the Facebook marketplace table listing by adding an accessibilityLabel to the TouchableOpacity element.

Example code:

<TouchableOpacity
  accessible={true}
  accessibilityLabel="Free, vintage table from the 1960s"
  >
....
</TouchableOpacity>

The code above adds the accessibilityLabel to the element that contains the entire button. We added "Free, vintage table from the 1960s" as the accessibilityLabel.

When screen reader hovers over the element with this attribute, it will read, "Free, vintage table from 1960's, button". This will let the user know the price, a brief description, and the fact that it's a button that they can click on.

This makes this particular element much more accessible for those that rely on screen readers.

Make Sure to Describe the State of the Element

In some elements, you'll need to describe the current state of a component to the user.

For example, if you have a checkbox, you should let the user know if the checkbox is checked or not.

Another common element you'll want to describe is whether buttons are disabled on a page. If the user cannot click on the button, then you should let the user know that there is a button, but it is disabled.

The below LinkedIn post page has an example of a disabled button. The button is not active unless the user types something in the post body:

Example:

Image

LinkedIn post page with focus on dimmed post button.

In the image above, focus is on the disabled Post button. When voice over is focused on that section, it says, "Post, dimmed, button". This lets the user know that this is a button, but they cannot click on it because it is dimmed.

Example code:

In the code below, when you focus on the button, it will say, "Button, dimmed" if its disabled button.

<Button accessibilityState={disabled ? {disabled: true} : {disabled: false}}>

Below are some other ways to let the user know about the state of an element. The screen reader will either say, "Menu item, selected" or "Checkbox, selected" if the menu item or checkbox is selected.

//Menu Item
<Button accessibilityRole={"menuitem"} accessibilityState={selected ? { selected: true } : { selected: false }} />

//Checkbox
<Checkbox label="Checkbox" selected={checked} accessibilityState={checked ? { checked: true } : { checked: false }} />

Context is Important

Since people listen to a description of the page when they're use voiceover, it's important that the context of an element makes sense and is not confusing.

This means that sometimes it makes more sense to group certain elements together. If there is more than one action the user can take in a particular situation, we should attach [accessibilityActions](https://reactnative.dev/docs/accessibility#accessibility-actions) to it.

Unhelpful Example:

Below is a screenshot I took from my LinkedIn app. This section is a link where if I click on it, I will go to another section of the app. This component also has a button where I can take more actions on this particular element.

Image

LinkedIn notification that says, "Is a bachelor's degree really worth it? Here's what a recent survey found."In first image, focus is on the title text. On second image, focus is on "6h" which is next to the title.

First, voiceover focuses on the title, "Is a bachelor's degree really worth it? Here's what a recent survey found". The next element that gets focused is "6h", then the focus goes to the three dots where the user can take more actions.

It's confusing when the screen reader says, "6h" – what does that mean? Users that can see the element can understand that this was posted 6 hours ago. But the screen reader just says "6h" which is confusing.

Also, in this one element, the user needs to focus on three different sections of it to derive all the intended meaning.

What would have been better for accessibility is if this component was grouped together and read, "Is a bachelor's degree really worth it? Here's what a recent survey found, posted 6 hours ago, actions available". This way, there is better context for the entire element.

Better example:

Image

Focused component that reads, "Front-End Engineer, AWS Data Wrangler, Amazon Web Services (AWS), New York, NY," with bookmark button on the right corner.

Above is an example of another section in the LinkedIn app. This section reads, "Front-End Engineer, AWS Data Wrangler, Company, Amazon Web Services (AWS), Location, New York, NY, actions available".

Although the word "company" and "location" are not on the screen, voiceover reads it to give better context for the user. Also, the bookmark button is not another element the user needs to scroll to focus on – it's grouped together, which gives better context for the user.

Example code:

<View
  accessible={true}
  accessibilityActions={[
    { name: 'navigate', label: 'navigate' },
    { name: 'bookmark', label: 'bookmark' },
  ]}
  onAccessibilityAction={(event) => {
    switch (event.nativeEvent.actionName) {
      case 'navigate':
        Alert.alert('Alert', 'Navigated to another page');
        break;
      case 'bookmark':
        Alert.alert('Alert', 'Bookmarked this link');
        break;
    }
  }}
/>

In the example code above, a screenreader will say, "actions available, swipe up or down to view custom actions".

When user swipes up, they will hear "navigate". And after, when they swipe one more time, they will hear "bookmark". If the user wants to select either option, they can double tap when they hear the option that they want. This way, actions have better context.

Wrapping Up

With small changes to your code, you can make apps much more accessible for all users. 12 percent of the United States population is living with a disability and no one should be left behind.

People with disabilities may use tools like screen readers and much more, and it's up to you to make your apps accessible to these tools.

It is everyone's responsibility to make sure tech is accessible to everyone. Thanks for reading!

]]> <![CDATA[ How to Setup an LED Light and Make it Blink with Code ]]> https://www.freecodecamp.org/news/code-behind-an-led-light/ 66d45f33230dff0166905811 Mon, 08 Jun 2020 21:50:21 +0000 Coding an LED Light is introductory project that shows you how software and hardware interact with each other. It's a simple project you can complete in a weekend that'll help you learn some basic aspects of hardware.

By the end of the project, you will code your own LED light, have the knowledge to manipulate the LED to on/off in intervals you choose, and learn basic principles of hardware.

The Elegoo Uno starter kit has all the hardware as well as instructions you need to make a simple LED Light. The LED Light is the first project offered with their kit.

Elegoo Uno comes with many other projects and takes you through from beginner to advanced projects. Each project in the box advances your skills in a simple, easy to follow way.

Components You'll Need

Elegoo Uno R3

Image

Elegoo Uno R3

The Elogoo Uno R3 is a microcontroller board. Microcontrollers are embedded inside devices to control the actions and features of a product. They are compact integrated circuits designed to control operations.

The microcontroller that is included in the Elogoo Uno R3 has 14 digital input/output pins, 6 analog inputs, a USB connection, a power jack, and a reset button. This board has everything you need to support the microcontroller. Simply plug in the USB Cable to turn the microcontroller on.

USB Cable

Image

USB Cable

You need a USB Cable to connect the Elegoo Uno R3 to your computer and turn it on. USB stands for Universal Serial Bus. The USB is used to connect your computer to devices such as digital cameras, printers, scanners, and external hard drives.

In our project, we will use a USB cable to connect our microcontroller to our computer.

LEDs

Image

LED Light

LED stands for light emitting diode. It has a positive and negative lead. The longer side is the positive lead.

How to assemble the components

Image

In this project, we are only going to make the LED blink.

First, we need to plug in the USB Cable to the board and then the computer.

Then we need to plug in the LED to GND (GND is the reference point in an electrical circuit from which voltages are measured, and is a common return path for electric current) and the 13 input on the board.

Code to make the LED flash on/off:

After the microcontroller board is plugged into the computer and the LED is on the board itself, we need to write some simple code to make the LED blink.

// the setup function runs once when you press reset or power the board

void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on 
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off
  delay(1000);                       // wait for a second
}

The code above basically turns the LED on for 1 second and then turns it off for one second.

This function is in a continuous loop. The digitalWrite is a function that takes in 2 parameters, LED_BUILTIN and HIGH || LOW . The loop basically takes in the LED, and then turns the volt to HIGH which turns it on. Then after 1 second it turns the same LED off by turning the volt to LOW .

Here's the Final Product:

The goal of this little LED Light Coding project was to introduce you to elementary principles of how hardware and software can be combined. I hope you enjoyed it!

]]>