advancebytes

Automated accessibility testing utilizes software to scan websites and applications for accessibility violations against WCAG guidelines. While they don’t cover all the specified standards, software covers up to 20-25% of them. This is better than 0. Automated testing is a great first step in identifying and fixing the low-hanging fruit, and those same series of steps can be applied to reporting to complete the cycle.

Web Accessibility Automation

Automation is a trend that shows no sign of slowing down; leveraging automation technology instead of human capital is changing the business landscape like never before. Saving businesses millions and lowering overhead expenses of running an online business.

Web accessibility testing is easier than ever with automation tools, such as LERA. There are countless benefits of automating your web accessibility testing.

Some of which are:

Let’s have a look at the benefits of automating your web accessibility testing and reporting. And how they can leave a positive impact on your business processes in the long run.

Web Accessibility Testing

Manual Testing or Automated Accessibility Testing?

Web accessibility testing can be divided into two groups: manual and automated.

Manually looking for accessibility violations on each page of your website takes a lot of time and money out of your pocket.

Instead of asking manual auditors to test your website every year giving you late feedback, using automation tools gives you near-real-time feedback on changes made on your website pages. And doing so on a consistent basis enables you to catch accessibility issues early in the development process.

This makes the whole testing process consistent across all your website pages, which translates into a consistent user experience for users with disabilities which is another key benefit. Automation also makes it easier for your development team to debug and fix accessibility issues.

Web Accessibility Crawl Scan

There are multiple ways you can scan your website for accessibility issues, one way is to run a crawl scan. Which starts by scanning a base URL, it then finds links leading to other webpages, scans them and so on and so forth until the whole website has been scanned for accessibility violations.

Running an automated web accessibility test is a great way to analyze parts of your websites that you probably had no idea existed. You can run them as much as you want and whenever you want.

What if a crawler detects no issues on your website, does that mean you don’t have any? Not necessarily, crawlers are a great way to find non-ambiguous issues on your web pages, this is not the case with ambiguous issues.

Some accessibility deficiencies will require a manual review from an auditor to verify. One such example is alternate text for images. It’s easy to run an automated scan and test whether an image has an alternate text or not, but how do you validate if the alternate text is appropriate? This can only be verified manually.

Talk to an Accessibility Auditor for help with manual code review of your web application.

Web Accessibility Reporting

Generating accessibility reports is often ignored or not given enough attention, yet it’s a crucial part of web accessibility. With automation tools, accessibility reports can be generated as often as you want depending on your business needs. Scheduling automatic reports helps keep accessibility top of mind for your whole team.

Legal And Compliance

It helps legal and compliance teams monitor risk, consent decree requirements and prevent legal actions against your business. It also helps them make sure that your organization respects accessibility compliance standards, the most common ones being WCAG 2.0 Level A/AA and WCAG 2.1 Level A/AA.

Development

Accessibility reports are useful for development teams as well, more often than not developers don’t think much about accessibility and are unfamiliar with WCAG rules. These reports can be used by developers to prioritize resources and focus their development efforts into solving high impacts issues first. It also helps in pinpointing where exactly these issues are occurring, and what proactive measures they can take to avoid them in the future.

Leadership

For leadership, accessibility reports and dashboards that focus on summarization are a great way to manage and have a birds eye view of an organization’s efforts towards accessibility.

Some of the default information that we track at AdvancedBytez are:

Contact Us Today to learn more about Custom Accessibility Reporting Dashboards!

Conclusion

Automating your web accessibility testing and reporting enables you to test your website as a whole, you get quick feedback and it’s easily scalable. Fixing accessibility issues at later stages of development is difficult. Running these tests early in the design and development process will save you time and money.

Generating automated accessibility reports enables your legal and compliance team to assess, monitor, and ensure that your organization respects accessibility standards. It helps your development team understand, troubleshoot and prioritize their development resources towards resolving urgent accessibility issues. And take proactive actions to avoid them in the future. It also helps leadership manage and stay updated on the organization’s accessibility compliance level.

Whether your development team is looking to QA bugs or convince your leadership that you are on the right track, we have an end-to-end solution to meet your needs – Manual, Automation and Managed Accessibility Services.

Talk to an Accessibility Engineer today to explore your needs.

Code linters are automated tools that evaluate source code for errors, bugs, and other issues. They identify common mistakes and coding styles that do not adhere to best practices, helping to identify and fix problems in your code before it is compiled.

An accessibility linter is a software program that analyzes the source code of a website or application and checks it against particular criteria, usually related to accessibility, to identify issues and potential problems.

Accessibility testing is a critical part of any software development lifecycle and the use of accessibility linters can be an invaluable tool to help catch and fix accessibility bugs before they become a problem. 

Benefits of Using Accessibility Linters 

Using accessibility linters is a great way to detect and fix accessibility bugs in source code before projects are compiled and deployed. Most linters are free, making them a low barrier of entry for developers to start using. They are also simple to use, and will integrate with your IDE and start finding and helping you fix bugs. 

The benefits of using accessibility linters include

Reduction of errors in production –

Using an accessibility linter is also a great way to prevent accessibility issues before they become a problem. By integrating an accessibility linter into the automated pull-request process, developers can ensure that all code is checked for accessibility issues before it is merged into the main branch. This helps to ensure that any code that is merged into the main branch is as accessible as possible.

Increased knowledge of accessible code –

In addition to helping prevent accessibility issues from becoming a problem, accessibility linters can also help developers learn how to write accessible code. By providing references to help developers better understand the accessibility issue, they can learn how to avoid making the same mistake in the future. This can be especially helpful for developers who are new to coding or are unfamiliar with accessibility.

Consistency of code –

Increased readability, maintainability and consistency of the production of code is possible by using the strict linting framework.

Consistency of style –

Linters ensure fewer debates concerning code style during code reviews.

Objective assessments –

Linters can provide an objective and measurable evaluation of code quality, which can help to prevent debates regarding code quality from descending into subjectivity.

As the overall quality of code improves this will reduce the level of effort required for manual accessibility testing. 

Popular Accessibility Linters 

Popular Accessibility Linters are open source tools used to detect and fix accessibility bugs in source code. These linters are typically integrated into IDEs and can also be used in automated processes such as pull requests and continuous integration and delivery (CI/CD). 

Some popular accessibility linters include ESLint, AccessLint, and Axe Accessibility Linter.

1. ESLint

ESLint is one of the most popular JavaScript linter which has a wide selection of library rules to help developers detect and fix common accessibility issues. It can be used in both Node.js and browser-based projects. 

There are different accessibility add-ons for each framework allowing you flexibility. ESLint supports React, Angular, Vue and JSX.

2. AccessLint

AccessLint is a linter that finds accessibility issues in your pull requests available as an app for GitHub. You can use AccessLint when a pull request is made, reviewing the changes and comments for accessibility issues, before code is manually reviewed. 

3. Axe

Axe Accessibility Linters is another popular accessibility linter. It is a free and open source automated testing library that can be used to detect and report on accessibility issues on 40 rules based on the axe-core rule engine. It is available for both web and mobile applications and can be integrated into IDEs, pull requests, and CI/CD pipelines.

The Axe linter supports linting for React, Vue, Angular, Markdown and HTML and is available for both Github and VS Code.

By integrating these linters into IDEs and automated processes, developers can ensure that their code is as accessible as possible.

How to Use Accessibility Linters?

These tools can be integrated with development environments and integrated into the automated pull-request process to detect and fix accessibility bugs before the project is compiled and deployed. 

Often, these tools can even provide references to help developers better understand the accessibility issue and prevent them from making the same mistake in the future. Accessibility linters can also provide valuable insight.

For example, some tools will detect and report on which accessibility criteria have been met and which have not. This can be a valuable resource for developers to identify areas of improvement or potential issues that may have otherwise gone unnoticed. 

They will then report any errors they find, and suggest ways to fix them. For example, if a linter finds missing alt text, it will suggest adding the appropriate alt text. Linters can also be used to detect potential keyboard traps, and flag any missing labels or form elements. Linters can be used to scan code in a variety of languages, such as HTML, CSS, JavaScript, and more.

Considerations When Using Accessibility Linters 

When using accessibility linters, there are a few things to consider. 

To get started with accessibility linters, first you need to choose which linter is best for your project. Once you’ve selected a linter, you can install it into your IDE and/or automated PR process. Once the linter is installed, you can start running it against your source code. 

The linter will then scan your code and report any accessibility bugs that it finds. Depending on the linter, it may also automatically fix some of the bugs. When using accessibility linters, it’s important to remember that they may not be able to detect all accessibility bugs. After all, automation only catches up to 25% of the bugs.

Conclusion

Accessibility linters are a powerful tool in the fight against accessibility bugs, and they offer a low barrier of entry for developers to detect and fix these bugs before they can impact users. However, linters can be limited in scope and not detect all accessibility bugs, so it is important to supplement them with other automated tools. Browser extensions are a great way to supplement linters, as they are usually accessible, simple to use, and can detect and reference a third of the WCAG Success Criteria.

With the right linter, you can start making your development process more accessible and make your applications more usable for all users.

Accessibility testing is crucial given the abundance of cross-platform mobile apps on the market. Testing professionals must make sure that mobile apps are well-tested from all user viewpoints because platforms, browsers, software, and tools are always improving. 

What exactly do we mean by evaluating mobile apps for accessibility?

A website or app’s usability for all internet users, including those with special needs or disabilities, is evaluated through software testing. Accessibility testing ensures that fixed conditions do not prevent someone with a disability from using online resources like everyone else. Usability testing is generally thought of as being within this category.

By testing mobile apps with actual users, usability testing ensures that users get the best possible experience. It assesses how user-friendly the mobile application is to navigate through and how well it matches user experience. 

Mobile App Accessibility: What does it mean?

A mobile app that is said to be accessible can be utilized by someone who has a disability. It’s possible that someone using software that reads web pages and apps aloud may suffer from vision impairment or have a reading disability. Or a person who watches videos with captions on because they are unable to hear well. For the more than 1 billion people with disabilities globally, it is crucial to develop mobile applications or mobile websites for smartphones, tablets, and wearables that they can use without any barriers. This is known as mobile app accessibility.

All of these users can use mobile websites and apps when they are created properly. Mobile technology, however, is frequently not created with accessibility best practices in mind. How come? Often, it is due to lack of awareness. Nobody wants to exclude any group from using an application intentionally. The best practices for mobile accessibility were taught to many developers without including the need for accessibility. When this is the case people with impairments are impacted. They also want to utilize online banking, buy, read the news, and communicate with friends and family online.

Accessible applications can make a big difference.  For example, engagement can be increased by doing something as easy as adding captions. Over the past eight years, captioning has improved video engagement by over 500%. And today we consume the most amount of media through our phones be it social media, OTT platforms or YouTube. The market for apps that make use of these forms of assistive technology will expand as more people continue to consume content over mobile devices. These functions and apps are available on even entry-level smartphones for those with disabilities.

Mobile App Accessibility: Why is it needed?

Millions of people use the internet every day, and many of them are active users who depend on the availability of internet powered applications on their fingertips. Literally. We all use our mobile devices for a variety of things made possible on the go. This calls for the development of apps that are quick and simple to use in remote locations and networks with poor connectivity. The inclusion of the broadest user base is a goal of designing accessible mobile and online apps, in addition to physical impairment.

A physical or mental condition that restricts a person’s movements, senses, or activities is referred to as a disability.  A disability can be cognitive, developmental, intellectual, mental, physical, sensory or even a combination of these types of impairments. Some users who require accessibility include:

Mobile App Accessibility Testing: Why It’s Important?

One of the abilities a capable mobile app tester should have is the ability to assess a mobile app’s accessibility. One reason for undertaking accessibility testing for mobile apps is to ensure that an application is usable by everyone. 

In a variety of circumstances, including legal, mandated, and inclusion, digital accessibility is becoming more and more crucial. Everyone, not just those with restrictions, benefits from it and it is the right thing to do.

The Checklist to Follow while Mobile App Accessibility Testing

1. General Instructions:

2. Touch Targets and Placement

Mobile devices’ increased resolution enables numerous interactive elements to coexist on a small screen. These components must be sufficiently large and spaced apart for users to reach them by touch. Especially when users need to use the mobile with quick gestures, the tap targets in the app should be large enough for user to interact with accuracy and confidence. The following are recommended touch target sizes:

Regardless of how the device is held, interactive elements in mobile apps should be placed where they are simple to access. Developers should think about how a button location that is simple for certain users might be challenging for others. Use with the left or right hand, for instance, or how far the thumb can move. The following are ideas for where to set touch targets:

3. Color Choice and Color Contrast

Verify the foreground-to-background color contrast ratio. To check if the ratio is more than 4.5:1 for normal text and 3:1 for large text and icons, you can use a tool like a Color contrast analyzer for iOS or the iOS Accessibility Inspector and Accessibility Scanner by Google for Android.  A low color contrast ratio makes the material harder to read. Avoid color combos like red and green when choosing a color as they may be challenging for those who are color-blind.

4. Different Designs for Different Screen Sizes

Mobile devices are distinguished by their smaller screens and unique aspect ratios. That needs to be considered by designers when creating native apps. The amount of information that can be viewed on a tiny screen is constrained, especially when the user needs to zoom in on the content owing to eyesight problems. The following ideas will assist users in getting the most out of small screens:

5. Consistent Navigation and Layouts 

Consistency in content, layout, and navigation are all important components of user experience. Those with weaker motor skills could have trouble using a mouse or keyboard. They frequently avoid using web browsers in favor of mobile apps. Users of all kinds can benefit from mobile apps with assisted navigation that leads them from one option to the next.

Additionally, layouts are a crucial factor in determining whether mobile apps are accessible to all types of users. 

6. Simple Data Entry Methods

Another distinguishing feature of mobile devices and native applications is multi-modal data entry, which allows users to enter data using a variety of methods, such as speech, a wireless keyboard, and an on-screen keyboard.

Other data entry methods can take the place of text entry, which can be time-consuming and difficult for some users. Simply integrate select menus, radio buttons, and checkboxes, or have information like date, time, and location auto-fill to lessen the amount of text entry needed. Since typing takes time, offering alternatives like data exchange between apps, autofill, or even dictation enhances the whole app experience and prevents mistakes.

What to use: Mobile Accessibility Testing Tools

There are several tools available to test for mobile accessibility on both Android and iOS platforms. Here are a few options:

iOS

  1. Accessibility Inspector: Accessibility Inspector is a tool that shows all the actions that can be performed by selecting and interacting with the elements on the screen.
  2. VoiceOver: A built-in screen reader for iOS that provides spoken descriptions of on-screen content and allows users to navigate through apps using gestures and voice commands.
  3. A11yTools: A suite of web accessibility testing tools coupled into an extension built by Paul J Adams, includes a mobile scanner for both Android and iOS devices. It checks for issues with color contrast, font size, and other accessibility features.
  4. Axe DevTools Mobile: A mobile version of the popular Axe accessibility testing tool by Deque. It is available as a free app on both Android and iOS platforms and provides detailed reports on accessibility issues within mobile apps.
  5. WAVE Web Accessibility Tool: This tool allows you to test the accessibility of mobile websites on both Android and iOS platforms. It checks for common issues like missing alt text and provides guidance on how to fix any problems found.
  6. Color Contrast Analyzer: A tool that allows you to test the color contrast of elements within your mobile app or website. It is available as a free app for both Android and iOS platforms.

Android

  1. TalkBack: A built-in screen reader for Android that provides similar functionality to VoiceOver. This is included by default in the Android Accessibility Suite. 
  2. Accessibility Scanner: A free Android app from Google that checks the accessibility of other Android apps on your device. It offers suggestions for improvements and provides links to relevant accessibility settings.
  3. Android Accessibility Suite: Android Accessibility Suite is a collection of accessibility services that help you use your Android device eyes-free or with a switch device.

Android Accessibility Suite includes 

It’s important to note that automated testing tools can only catch a portion of accessibility issues, and manual testing is also necessary to ensure that your mobile app or website is fully accessible to all users.

Ending Note:

Traditionally, web accessibility has been neglected. In recent times we have seen an uptick in the importance of removing barriers to the web due to rising lawsuits and inclusion movements. However mobile app accessibility still has a way to go in terms of its importance. Spending money and time upfront on accessibility is far more cost and time effective than resolving accessibility problems after the application has been launched. A more extensive audience will be exposed to an app with good accessibility than one with bad accessibility. Additionally, it will enhance user experience and hence support a wider user base.

Get in touch with our accessibility auditors to help you evaluate the accessibility of your mobile app today.

Why Should You Automate Web Accessibility Testing?

Simply because manual testing takes time and is costly. Automation saves you time, effort and money. Leveraging automated tools and software is a great way to offload that workload. By automating your web accessibility tests, you will have more time to focus on what matters the most for your business. 

5 Great Benefits Of Automated Web Accessibility:

What Is Axe-Core?

Axe-core is the world’s leading automated accessibility testing engine, it’s simple to use, lightweight and highly configurable.

It is used for checking accessibility violations on websites and HTML-based user interfaces. Axe-core can find 57% of WCAG issues automatically. It will also return elements as ‘incomplete’ where Axe-core is not certain, for further manual review. Axe-core needs a browser to run, which is why it’s often used with automation tools like Selenium.

The Benefits Of Using Axe-Core: 

Axe-core supports the following web browsers:

It supports the following accessibility standards:

What Is Selenium?

Selenium is an open-source user interface automation testing suite for web applications. Selenium can automate all modern web browsers and it runs on all major operating systems. Selenium scripts can be written in Python, Java, C# and more.

Three Main components for the Selenium suite:

Selenium WebDriver

The Selenium WebDriver is a tool that allows developers to automate web browsers. It’s mainly used for automating testing of web applications. You can create scripts that automate tasks in a web browser, such as clicking buttons and links, filling forms and verifying that certain elements are present on a page. It allows you to quickly and easily test the functionality of a website. Selenium also gives you the option of either running a web browser headless or non-headless. The key difference being that a headless browser runs in the background without a graphical user interface (GUI) and is usually faster. And a non-headless browser runs as a real browser with a graphical user interface.

Selenium IDE

The Selenium IDE is a browser extension for Google Chrome and Firefox. It’s beginner friendly and works out of the box. With its simple UI, you can easily automate website testing in a couple of clicks. It has extensive control flow commands like if, while and times. It can also be extended with plugins for more commands and integration with third-party services. 

Selenium Grid

The Selenium Grid is used to run multiple instances of WebDriver scripts on remote machines. This is useful if you need more processing power, it’s also a great way to test on different browser and platform versions.

Setting Up Environment to run an Automated Web Accessibility Audit

Let’s see how you can set up your environment to run an automated web accessibility test using Axe-core, Selenium and Chrome Driver in Java:

1. You should already have Java JDK installed and downloaded ChromeDriver, as we will be using Chrome as our web browser to test web accessibility.

2. We will be using Maven as our project manager, so you should already have created a Maven project.

3. Now let’s open the pom.xml file inside the Maven project you’ve just created and add the following dependencies:

<dependency>
  <groupId>org.webdriver</groupId>
  <artifactId>selenium-java</artifactId>
  <version>3.141.59</version>
</dependency>

<dependency>
  <groupId>com.deque.axe-selenium</groupId>
  <artifactId>axe-selenium-java</artifactId>
  <version>4.0.0</version>
</dependency>

4. Now run nvm install inside your Maven project directory to install the dependencies.

5. Now you should be able to run Axe-core and Selenium inside your Maven project. 

Let’s run a test script! 

Running A Basic Test In Java

Here’s a simple script written in Java that uses Axe core, Selenium and Chrome Driver.

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

import com.deque.axe.AXE;
import org.json.JSONArray;
import org.json.JSONObject;

public class AccessibilityTest {
public static void main(String[] args) {
    // Set up Chrome driver
    System.setProperty("webdriver.chrome.driver", "/path/to/chromedriver");
    WebDriver driver = new ChromeDriver();

    // Open the page to test
    driver.get("http://www.example.com");

    // Run Axe-Core
    JSONObject response = new AXE.Builder(driver, "axe.min.js").analyze();

    // Print the results
    JSONArray violations = response.getJSONArray("violations");
    if (violations.length() > 0) {
        System.out.println("Accessibility issues found:");
        for (int i = 0; i < violations.length(); i++) {
            JSONObject violation = violations.getJSONObject(i);
            System.out.println(violation.getString("help"));
        }
    } else {
        System.out.println("No accessibility issues found.");
    }

    // Close the driver
    driver.quit();
}
}

This is how the script works:

1. This script launches a Chrome Driver instance.

2. It loads the website we want to test.

3. It then runs Axe-core and injects axe.min.js into the webpage.

4. Finally, it outputs the results to the console.

Conclusion

Running automated web accessibility tests is easier than ever with Axe core and Selenium. Manual testing takes time, effort and money. Implementing an automated solution is the best thing you do for the future of your business.

Overall, automating web accessibility tests will improve the accessibility of your website and make it more inclusive for users with disabilities.

ARIA stands for Accessible Rich Internet Application. ARIA is a collection of attributes and roles that act as add-ons to complement HTML for complex web applications, particularly those built using Javascript. 

It helps make the applications accessible for assistive technology that is otherwise not possible with the use of native HTML alone. Some examples are dynamic content and user controls like error messages, tool tips, live regions. 

Becoming ever so popular with web developers looking to make applications accessible, ARIA if misused can cause an inaccessible experience for a user. Which is the case today, as we see code stuffed with ARIA. It helps understanding the WAI-ARIA rules, which are not easy to decipher so we have tried to explain it in simple language. 

Let’s take a look at the 5 rules of ARIA below with some examples. 

ARIA rule # 1: Don’t use ARIA!

If you can use a native HTML element or attribute instead, then do so.

If you shouldn’t use ARIA, then when can you use it?

If it’s not possible use a native HTML element or attribute because:

Here is one common example of incorrect ARIA usage, I’ve seen:

(I had to mediate an argument between a dev and a tester just last week 🙂)

𝗛𝗲𝗿𝗲 𝗶𝘀 𝘁𝗵𝗲 𝘀𝗮𝗺𝗽𝗹𝗲 𝗰𝗼𝗱𝗲:

<a href=”/example.com/about/” role=”button”> Read more </a>

𝗪𝗵𝘆 𝗶𝘀 𝘁𝗵𝗶𝘀 𝗶𝗻𝗰𝗼𝗿𝗿𝗲𝗰𝘁?

Role = button tells a screen reader it is a button element,

But it doesn’t provide the functionality of a button.

So they tried to “fake” it as a button by using an <a> tag.

𝗧𝗵𝗲 𝗰𝗼𝗿𝗿𝗲𝗰𝘁 𝘄𝗮𝘆:

<button type=”button”>Read more about ARIA </button>

𝗪𝗵𝘆?

<button> is a native HTML element and is perfectly accessible.

Here is a Link to ARIA cheat sheet. One of the best I’ve seen in the industry and I’d highly advise you to refer to it when in doubt. 

ARIA rule # 2 : Do not change native semantics, unless you really, really, truly have to.

For example: A developer wants to build a heading that’s a tab.

Do not do this:

<𝗵𝟮 𝗿𝗼𝗹𝗲=𝘁𝗮𝗯>heading tab</𝗵𝟮>

Do this:

<div 𝗿𝗼𝗹𝗲=𝘁𝗮𝗯><𝗵𝟮>heading tab</𝗵𝟮></div>

The Role feature: Defines what an element does.

Some roles duplicate the semantic value of HTML5 elements : nav, aside

Others describe the page structure : banner, search, tablist, tab

ARIA attributes don’t affect the web page itself.

They only provide information to screen readers.

Use ARIA wisely.

ARIA rule # 3 : All interactive ARIA controls must be usable with a keyboard.

Native HTML interactive elements are keyboard accessible.

A custom control, needs to receive focus and the user be able to activate it with:

Enter (Windows) or Return (Mac) keys, and Space key

What this means in simple terms is:

A custom control like a button for example, must work with the keyboard as a native button element would.

𝗖𝗼𝗺𝗺𝗼𝗻 𝗺𝗶𝘀𝘁𝗮𝗸𝗲 1

Buttons created using <span> or <div>

𝗛𝗼𝘄 𝘁𝗼 𝗳𝗶𝘅:

Create button using <button> or <input>

Common mistake 2:

Links created using <span> or <div>

How to fix:

Create links using <a>

Common mistake 3:

tabindex = “-1”

How to fix:

tabindex = “0”

𝗤𝘂𝗶𝗰𝗸 𝗻𝗼𝘁𝗲 𝗮𝗯𝗼𝘂𝘁 𝘁𝗮𝗯𝗶𝗻𝗱𝗲𝘅:

If you create an interactive element yourself, use tabindex to make it focusable

tabindex = “0” adds focus

tabindex = “-1” removes it from the tab order

screenshot of code using div with tabindex=0 to make an element focusable.

ARIA rule # 4: Don’t use role = “presentation” or aria-hidden = “true” on a focusable element.

Let’s understand the attributes first.

role=”presentation ” or role =”none” removes the ARIA semantics from the accessibility tree.

When is it used?

When an element is used for presentation only and does not have accessibility purposes.

aria-hidden is also used to hide non-interactive content from a screen reader.

When is it used?

When you want to hide elements like:

Decorative items like icons or images that have no meaning/context

Collapsed items such as menus

Duplicate content

When are the attributes used?

aria-hidden =”true” will remove the entire element from the accessibility tree.

role=”presentation ” and role=”none” will remove the meaning of the element but still expose its content to a screen reader.

ARIA Rule # 5: All interactive elements must have an accessible name.

Accessible names help assistive technology users understand how to interact with an element.

Let’s look at what interactive elements are. 

Interactive elements are:

An accessible name can be generated from a native HTML element’s content:

<button> uses the content between the opening and closing tags as its accessible name </button>

The <label> in a form will pull the content associated with its input as its accessible name.

If none of these options are available, use aria-label to define the accessible name of the element:

aria-label – text that labels the element is not visible.

aria-labelledby – visible text that labels the element.

aria-describedby – additional instructions for the input to users.

Conclusion

Now we understand what ARIA is and how it is used. We’ve also seen the benefits of using native HTML to make applications accessible out-of-the-box. 

My key takeaway to prevent “excessive” ARIA use is by remembering one thing:

You don’t always need to provide instructions to screen readers only.

If the instructions are important enough, provide them to every user.

That’s what makes the best user experience.

Accessible products don’t just happen. They start well before development, at the planning and design stages. It’s essential to start thinking about accessibility early and ensure you’re testing for it at all stages of the design and development lifecycle, including wireframes.

In this post, we’re focusing on steps to ensure that wireframe designs for new websites or apps are created with accessibility in mind. Make sure your team is trained to review wireframes thoroughly and that developers understand

How to translate clear wireframe designs into accessible HTML CSS content.

Cost-effective design

A good incentive when reminding designers to incorporate and check for accessible features is understanding the cost benefits. “Shifting left” to review and address accessibility issues early reduces the number of changes and fixes required down the road.

Annotations and explanations

Include annotations to explain the intent of design details. These can be provided as textual notes or as graphical flow charts or images. Be sure to explain the design intent so developers can decide how to create features in a way that is accessible for all users. For example, use annotations to describe the preferred appearance of the hover and focus states for buttons, so keyboard users will have a visual indication of the currently focused control.

Clear labels

When creating label names in the wireframe, think about the purpose and function of controls and links for the user, not the developer. Ensure that label names are logical and intuitive. Make sure they’re also unique on each form, for both usability and easier searches.

Labels should use plain language, avoid uncommon slang, acronyms, or terminology, and be simple and easy to understand for all users. For example, if an assistive technology user hears a screen reader describe a label or control as “previous” or “current,” this is not as helpful as clarifying “Previous Employer” or “Current Employer.” Similarly, links should describe briefly what the link will lead to or open, rather than just indicating, “Click here.”

Heading structure

Assistive devices like screen readers use tagged headings and subheadings to navigate web pages and sections of digital content. This helps individuals with low vision or those using assistive devices to search or scan content, by choosing to hear all the headings on the page.

Nested heading structure is an essential feature for content accessibility and organization. The wireframe designer should include a clear list and description of all headings and subheadings. Without documentation, a developer likely will not be able to determine the structure. Take time to double-check that the heading structure is consistent and logical, with subheadings nested in the appropriate order. 

Focus order

Focus order – clarifying the order that elements on a page receive keyboard focus – is essential information for keyboard accessibility. Wireframes should indicate the focus order information clearly and specify the visible focus state.

Document hidden wayfinding cues

Users of screen readers benefit from wayfinding cues that can help them navigate a webpage. For example, including instructions for when to include “Bypass block links” allows screen reader users to skip over repetitive and unnecessary blocks of content rather than tabbing through unnecessary information. Refer to WCAG 2.4.1 for more information.

Describe these repetitive blocks in the wireframe so that developers can include these wayfinding cues. This helps ensure that users can tab once into a content area, but then skip to the next content area if they choose.

Testing wireframes

It’s challenging to do usability testing on a non-existing system, particularly with people with different types of disabilities (for example, dexterity, visual, hearing, cognitive). If it’s early in the design stage, try to find a similar tool or task on a functioning system and test its accessibility with users with disabilities.

If issues arise that are identified as “accessibility” bugs, ensure that these are prioritized and included with the rest of the workload and not as lower priorities that can be addressed after “core” features.

Taking the time to design clear wireframes and consider the accessibility for all design elements helps ensure that the wireframe is complete and usable for developers. Ideally, tested and approved wireframe designs can then be used as templates to help create accessible products with similar branding.

How AdvancedBytez can help

Beginning design review and testing as early as possible can solve or prevent up to 67% of potential bugs. This number is frequently referenced in the accessibility industry, and refers to a Deque case study. 

The typical steps to review wireframe designs include (1) a site map design review, (2) a review of the layout with no color, followed by (3) a review of the layout with color. 

1. Site map design review 

Following a Shift-Left approach, AdvancedBytez encourages our clients to begin their accessibility design review at the site map stage. 

Technically, the site map is a hierarchical listing of a website’s pages. Practically, it should act as an ongoing guide for developers for each project, providing details about each page’s purpose, content, functionality, and flow.

AdvancedBytez can review your sitemap design and help ensure that it includes all items needed for clear and accessible utility navigation, main page and secondary pages, and footer navigation. We can provide recommendations for clear guidelines, logical page content, and suggestions for combining or eliminating pages. 

A sitemap design review will help ensure a clear, concise, and accessible flow to help your developers create a user-friendly, accessible website.

2. Review of wireframe layout with no color

Also referred to as a low-fidelity wireframe review, AdvancedBytez tests low-fidelity wireframes (the foundation of visual designs but without colors or images) by focusing on accessible placement of assets and content for each template. 

screenshots of Low fidelity wireframe without color indicating displaying page layout and elements.

Working with designers and design teams, elements such as buttons and interface widgets are tested with a screen reader.   

3. Review of wireframe layout with color

High-fidelity wireframe testing involves reviewing a more complete representation of the end product. 

After any design changes are made based on earlier site maps and low-fidelity review feedback, we then test color contrast, font usage, and complex interactions. In this third stage, we review usability and provide results of user interaction testing with the graphics, spacing, and user interface (UI).

screenshot of hi fidelity wireframe with colors for all the elements including background and font.

Sitemaps and wireframes take time to create because they’re essential tools in helping developers create usable and accessible websites and apps. 

Make sure your team is trained to review wireframes thoroughly and create clear and complete guidelines for your developers. Consider having AdvancedBytez test these tools–we can help ensure developers have everything they need to translate design wireframes into accessible HTML CSS and user-friendly content.

If you are a small business owner, you may or may not have the skillset to build an accessible website from scratch. If learned, this simple skill can save you a whole lot of money that you can invest elsewhere. 

WordPress is one of the most popular platforms to build websites, and 43% of websites are built on this platform globally. With WordPress’ visual components, anyone can build a website on this platform. And, there are many tutorials that can help you in each step of this process. 

But what about accessibility? 

Building accessibility into the web development process right from the design phase is essential to avoid future rework. This includes starting from the branding and progressing to sketching out the navigation and page structure even before starting on the development. It would increase your site’s outreach as everyone, including people with disabilities, can also access your website’s information. 

In this guide, we’ll discuss all the steps that you should consider for building an accessible WordPress website. So, let’s get started. 

Things to Consider while building an accessible WordPress website

Part 1: Accessible WordPress Themes

There are many free accessibility ready themes available and even some paid ones on Theme Forest. 

First, what is a Theme? 

A WordPress theme is a set of files compiled together that include page templates written in PHP, CSS, and some Javascript. It is a ready to use tool that defines the layout and design of your website. Themes set the appearance of the site that includes the page layout, color palette, typography, and other design elements like buttons and menus. 

When you first install WordPress there is a default theme that comes with it. You can change the theme to meet your needs. 

Themes and Accessibility

Choosing the right theme will make your website easier to navigate, look good and provide a good user experience for your visitors. 

It’s that much more important when it comes to Accessibility to choose the right theme. We know that a theme outlines markup, navigation, layout and design elements. An accessibility ready theme is responsible for making these accessible already so you don’t have to hand code it. 

Some items to look out for when selecting an accessibility theme-

You can test this by hitting the tab key on your keyboard. 

A link should appear at the top left hand corner of the webpage right under the address toolbar that says “Skip to main navigation” or something similar. 

You should also be able to access links, buttons, and form fields with a keyboard only. 

How to find Accessible Themes?

We would suggest that you do your due diligence and research each of the themes by visiting the theme homepage and check for the features mentioned above. 

You could always stress test them by installing the themes and trying to navigate with a keyboard or a screen reader to see if they are actually accessible. A little bit of research will go a long way. 

We are big fans of WebMan Design by Oliver Juhas who makes EU compliant Accessible themes. 

Some of his popular themes are:

Part 2 : Create an accessible WordPress theme 

WordPress gives you the option of building an accessible theme on your own. 

If you are a little more confident about your technical skills, you can go on to build an accessible theme. 

For most of our clients who require custom builds, we use Underscores as a starter theme and build upon it to have more control over the page templates. 

Some other good themes to customize are Astra, Genesis and GeneratePress.

Once you select your base theme to modify you can follow the following steps to build upon it:

Here is a non-exhaustive checklist to look out for when building your accessible wordpress site:

Adding alternative text for media files 

Most websites these days are filled with media-rich, non-textual content. While we understand that this is a great way to engage your website visitors, this could be a reason why people with disabilities are unable to access the information on your site. 

People with disabilities use a screen reader to access the information on websites. A screen reader can only depict text content and it cannot describe the images to the visitors. Similarly, if you are starting a podcast, someone with hearing disabilities cannot access it. 

One of the best accessibility practices that can simplify this situation is adding text alternatives, wherever you use images or other media files. It will work as a descriptive text to the image you are using and guide people with disabilities regarding the information underneath. 

Source 

Adding alt text to a WordPress site is pretty easy, as you can see in the above image, there is a specific place for adding alt text, for each image you upload. So, there should be no difficulties in doing this right. 

Similarly, if you are planning to start a podcast, it is ideal that you add transcripts so that a user who is unable to access the audio can still consume the information you are sharing. 

Add link descriptions 

Assistive technologies like screen readers jump from one link to another to navigate across your website. So, to make sure that the users are reaching the right web pages, it is recommended to add appropriate link text and descriptions. 

When using a Call-to-action, don’t use generic link texts like “Add link descriptions ” or “Find out more”. Replace these CTAs with “Click here to read about…” or something that conveys the purpose of the CTA to people with disabilities. 

Source 

Typography 

Size 16px is the recommended font size for the body text, also ensuring that the text can be zoomed to 200% without being distorted. 

Fonts that belong to the Sans Serif family are recommended for readability, and here are some of the fonts that we recommend:

FONT NAMECOMMENTS
VerdanaCommonly found font designed by Microsoft
Lucida SansLarge x-height making it readable at all sizes
TahomaAnother Microsoft font
HelveticaTraditionally a print font, it is available on most Operating Systems by default 
Arial Similar to Helvetica 
CalibriCommonly found font in Windows with good distinct characters 

Pro tip: When using CSS, set the font size in relative terms (%, em). This will allow fonts to be displayed relative to a particular device that it is being displayed on. 

Semantic Headings

A structured heading order benefits screen readers, visual users and Google. Google? Yes, it helps in SEO when you have a semantic heading structure. Read this article on SEO and Accessibility to learn more about the relationship between the two. 

Heading best practices:

Follow a logical heading order without skipping heading levels. 

A good heading structure would look like the following

<H1>

<H2>

<H3>

<H3>

<H4>

Skip Links

As we mentioned in the features to look out for when selecting WordPress themes, skip links are necessary for screen readers to bypass long chunks of navigation and go straight to the main content on the page. 

They are usually controlled by CSS and can either be hidden or made permanently visible above the header. In most cases, they are hidden by CSS. 

This is how the HTML would look like –

<header>

<a href=”#main” class=”skip”>Skip to main content</a>

</header>

<main id=”main”>

A main ID is needed to link it with an anchor. 

Because we had a skip class in the HTML, we will be able to hide it with CSS. 

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

The link needs to be focused when it is visible, and this is controlled by CSS as well

.skip:focus {
    position: static;
    width: auto;
    height: auto;
}

Use of Native HTML elements

If you use native HTML elements the way they are meant to be used, you will have a perfectly accessible website and won’t even need to use ARIA. 

This is because native HTML elements are accessible by default especially <button>

Keyboard Accessible Navigation

A user should be able to navigate through a page by using Tab to move forward and Shift + Tab to go backward. 

Enter and Space keys should activate the element. 

All interactive elements should be navigable and activated with the keyboard. Some interactive elements are:

Visible Focus

Not all users use screen readers, but use a keyboard only to navigate a page. When they do, there needs to be a visible focus indicator around an interactive element.

You can use the syntax :focus-visible to apply a focus outline. 

Tabindex 

Tabindex is very useful in setting the order of the focus as a user traverses through the page using the tab key. 

When and How to use Tabindex values

tabindex = “-1” 

This value doesn’t put the element on the tab order of the page. 

tabindex = “0”

Will make an element focusable. 

Tabindex > “0” 

Any value greater than 0 is not recommended as it makes it difficult for users of assistive technology to navigate and interact with the page content. 

For example, tabindex = “3” means that the element will be focused in the order defined by the number value. So tabindex = “1” and tabindex = “2” will have to be focused in order before arriving at tabindex =”3”. 

These are only scratching the surface of WordPress accessibility, but it’s a good place to begin. The use of HTML and CSS best practices will help solidify a base for good user experience and an accessible website. 

Part 3: Accessibility testing and reporting 

Accessibility testing should be performed at every stage of building a website and before moving onto the next process. Use a free, automated Chrome extension called LERA to : 

Final Thoughts 

Building an accessible website on WordPress is not difficult at all as you don’t need excessive technical skills to use this platform. If you select a good accessible theme and use it as intended out of the box without modifying it too much, you will be set up with a good accessible website. 

If you require custom accessibility compliant websites in WordPress you can reach out to us at info@advancedbytez.com.

Happy Coding.

Understanding the need for accessibility

Why aren’t all new digital products accessible?

A major reason is that not everyone views accessibility as a mandatory requirement. Accessibility is too often seen as optional and only prioritized if time or resources are available. But access for everyone is becoming a requirement throughout the web development lifecycle and not just an extra feature.

A common misconception is that minimal compliance with accessibility legislation results in accessible products and services. But it takes more than that. To produce a truly accessible product, responsibility needs to be shared across product teams. Specific responsibilities need to be assigned to and carried out by individual team members.

How successful someone is in carrying out their role is based partly on their understanding of how to use tools and technology. But another big part of success is their awareness of the importance of accessibility.

Everyone has a role

Everyone involved in developing digital technology has a role. Before assigning responsibility (or blame) to different IT roles or departments, begin by making sure that each of your team members understands the importance of accessibility. Ask this question to each team member, starting at the top of the organization and at each project launch: “Is accessibility viewed as a priority by everyone and do you know how to create an accessible product?”

Understanding the objectives of the Web Content Accessibility Guidelines (WCAG) standards might mean that designers and developers need to look at the web development lifecycle differently. To create an environment where everyone feels responsible for creating accessible products can mean that planning, hiring, training, design, content development, and testing practices of an organization might need to change. And change is never easy, even when it’s needed.

Who’s responsible for creating accessible digital products?

Ultimately, everyone is responsible for accessible digital design. Whether you’re involved in the planning and design stages, development, or content creation and testing, all teams need to consider accessibility and to work together.

In its Inclusive Design Toolkit, the Ontario government describes the following roles as being responsible for the accessibility of digital design.

Source: https://www.ontario.ca/page/inclusive-design-toolkit

Some readers might be thinking that it’s unrealistic – particularly for smaller developers and businesses – to have all of these team members available for all development projects. Keep in mind that having this many designated team members represents an ideal but all too rare scenario. There are options available for smaller organizations that are committed to accessibility but who don’t have the resources available to create a range of dedicated accessibility roles.

For example, having or assigning an in-house Accessibility Coordinator or accessibility champion can help ensure there’s one point of contact for the rest of the development team to consult. That individual can stay up-to-date on best practices, provide guidance and troubleshooting support at various stages of design and development, and collaborate with external groups when needed.

That said, if your organization has the resources to build a broad digital accessibility team, here’s a breakdown of the ideal accessibility team members.

1. Policy and Research team

Policy and Research teams research and explains user needs to those funding and developing the product, making sure that the needs of people with disabilities are included. The Product Manager prioritizes tasks of the digital product being developed, including accessibility activities. An Accessibility Advisor or “guru”, preferably with lived experience as a person facing barriers to accessibility, provides training and advice throughout the project, as needed.

2. Project Manager

The Project Manager has an essential ongoing role, responsible for considering accessibility at each step of the web development lifecycle. They assemble the product development and testing team, ensuring communication of the requirement for accessible web & software development, and with support for accessibility training where needed. They allocate responsibilities and resources as needed to support a commitment to accessibility. And they review accessibility at each milestone, ensuring that they are aware of any accessibility limitations and assigning resources to resolve issues or plan for workarounds.

3. UI and UX Designers

The UI and UX Designers understand accessible design requirements. They work together to design a product look and feel with accessible design elements. This includes an appropriately high level of contrast, accessible fonts and layout, and an intuitive design of required accessibility and product features. They then ensure that usability and accessibility of the design are tested and involve both commonly used assistive devices and people with various types of disabilities.

4. Developer

The Developer is responsible for implementing accessible code. How developers use programming languages creates a presentation layer. Since web or app developers are responsible for coding interfaces, they are responsible for translating needs, tasks, and design goals into technical applications. Their work determines how the user interacts with the digital product and how the product responds to input.

The front-end development function covers tasks and quality control associated with HTML and CSS integration, as well as the programming of proposed scripts and applications. There’s a way to guide screen reader software, and even some of the hardware inputs, by using effective HTML, CSS, and JavaScript.

5. Content Writer

The Writer creates and edits written content with accessibility in mind, including use of plain language and testing of reading level. They are responsible for writing clear labels and structuring content with a logical, clear flow. Content needs to be structured in a user-friendly and intuitive way for navigation. Anyone using the page should be able to understand what the main sections of the site are and be able to navigate through the content.

6. Quality Analyst

QA then follows a test plan that ideally incorporates testing for accessibility. When QA checks for problems and tests for accessibility, preferably working with users with disabilities. Assessing an interface and product design and functionality in terms of accessibility helps uncover issues that generally have impact on all users. Ideally, testers should have standard scripts they can run related to accessibility requirements and features. QA testers are often the “last line of defense” in identifying accessibility issues. These should be returned as bugs and be fixed as priorities before a digital product is released.

Create an inclusive team

Creating an inclusive team is a big part of creating an inclusive work environment and inclusive products. When designing and developing digital products, be sure to include people with disabilities and from other underrepresented groups on your team.

Ensuring diversity in your product management, design, research, development, and test teams will lead to digital products that are accessible to a broader audience and, ultimately, to more success for your organization.

How can AdvancedBytez help?

Whether you’re a small or large organization, AdvancedBytez can help support your accessibility team. Contact us for information on our services, including:

·      A free consultation – Discuss your needs with an AdvancedBytez digital accessibility expert. 

·      An accessibility audit – We can assess your application and provide a detailed manual audit against various WCAG conformance levels. 

·      Remediation support – We’ll recommend solutions for identified issues and help fix your code to create a more accessible application.

·      Accessibility tools – AdvancedBytez offers a free automated accessibility reporting tool, LERA. Available as a Chrome browser extension for Windows, LERA scans for automated issues and creates a report available for download as a pre-formatted Excel sheet.

Why Digital Accessibility Matters?

Diversity, equity, and inclusion are mentioned as business priorities more and more in the past few years. Ensuring your business and its products and services are more accessible to all creates a more inclusive society.

Digital accessibility is a big part of creating an inclusive environment. When leadership and team members understand the importance of inclusion and why digital accessibility matters, it’s much easier to implement policies and practices that your team will adhere to.

At least 20 percent of the population * self-identify as living with one or more disabilities that affect their day-to-day lifestyle. And this number is growing, due to an aging population, due to COVID-19 and the related increase in long-term and chronic health issues, and due to reduced stigma in self-identifying as a person living with a disability.

Businesses already need to comply with accessibility and human rights legislation. They also don’t want to exclude approximately one-quarter of the population as potential customers.

Accessible design is not just for the “disability market.” Curb cuts at intersections were originally designed to assist people using wheelchairs and walkers cross the street safely. Most people would agree that these “accessibility features” work better for everyone. Accessibility features in technology work the same way – they create more options and better experiences for all users.

As a project manager or software developer, It’s important to ensure that digital accessibility is built into your team’s product development lifecycle. The key is to start at the beginning of the process and make sure you consider accessibility at each step along the way.

Here are some hints and tips to help ensure you’re creating more accessible and inclusive products.

Accessible Product Development Starts with Shift Left

With a traditional create, break, then fix approach, developer resources often go towards fixing or redesigning issues late in the process or after software is released. This can be an inefficient and costly use of resources, keeping businesses in a reactive cycle of addressing problems and complaints.

When product development stages are viewed as a left-to-right linear process, incorporating testing earlier in the process is a “shift left” from the traditional development cycle. Shift Left has become more common for developer teams because it can deliver better quality code and lower the cost of creating digital products.

For developers to avoid creating accessibility barriers, you need to build digital accessibility into the entire product development lifecycle. Start early, with research and planning, product design and development, user testing and QA, marketing, training, and customer support. This creates a more efficient, user-friendly, and budget-friendly process.

Why Accessibility Matters at Every Stage?

Even before a project is confirmed, it’s important to consider how accessibility for all users can be addressed in establishing a project’s goals and objectives. Before a commitment is made to launch a new project, take time to research current accessibility requirements and best practices.

1. Start at the planning stage

The project manager sets the tone of the project. Their attitude and communication, their decisions and actions, guide the rest of the team. They need to understand both legal requirements and organizational goals and priorities related to accessibility. And they need to communicate these goals and priorities clearly to team members.

Is the project manager familiar with WCAG standards, AODA (or ADA or other legislative) requirements, current technology used by people with disabilities, team members with training and/or lived experience with dealing with accessibility barriers, and how and when to test for accessibility during design and development?

Developers, testers, and team leads assigned to a project must be familiar with accessible product design. If no experienced or trained resources are available, it should be a requirement that new hires are sought or that the time and resources will be available for project members to receive adequate training prior to project launch.

Nothing communicates a priority as much as where time and money are invested. Leadership (and money) comes from the top.

2. Build an inclusive team

Do your HR team and hiring managers understand how to build an inclusive team with members who understand the need for digital accessibility as a priority? Do they include “knowledge of WCAG” or “an understanding of accessibility best practices” in job postings, interview questions, training and performance management goals, and evaluation processes?

Make sure your organization is building a diverse and inclusive team and that you don’t stop growing because you’ve identified one or two “accessibility people” on hand for short-term use.

Every team member should be aware of accessibility barriers they might be contributing to and what they need to do to remove or prevent those barriers.

3. Know your audience

How will your customers use the product? It’s important to understand different input and interaction styles, and different settings of various assistive devices. Which browsers, operating systems, and devices are you designing for and supporting? Are these compatible with current and common assistive devices and accessibility tools? What software will be used to design, development, and test the product?

How many of your developers have actual experience working with people with disabilities as they test a product? How many have seen how various assistive devices or tools work (or don’t work) with the software they’re developing? Direct contact with end users helps create better products.

4. Include accessibility as a success criteria

What does success look like, for your organization, your project, your product, and your users?

Who is involved in determining acceptance criteria for accessibility? It takes more than just adding a Web Content Accessibility Guidelines (WCAG) checklist or style guide to the testing process to create truly accessible and inclusive products. But a few more steps are needed to ensure user-friendly, engaging, intuitive, and effective online products.

WCAG 2.1 AA is considered a minimum requirement by most legislation, but higher standards are becoming more common and expected when adopting best practices. Is your team including accessibility features such as creating style tags with CSS rather than HTML elements; ensuring videos have captions and, ideally, transcripts available; or providing accessibility troubleshooting information to customer support teams?

5. Accessibility is an ongoing goal

After the product is developed and is being used by customers, it’s important to continue monitoring its success. Does the product work for its users? How do you know? Is the process for users to provide feedback and complaints accessible and easy to use? How are complaints tracked, monitored, and resolved?

Do your customer support and software maintenance teams understand potential accessibility issues or barriers with the final product? Have they been trained on how to communicate with people with various types of disabilities? Are they aware of how to assist users facing barriers with problem solving or workarounds?

6. Ensure that accessibility is part of every product development process

Following a project, project reviews or post-mortems are often held. Feedback and learnings from mistakes are not always applied to create improvements in future projects.

When it comes to identifying accessibility mistakes or barriers that have been created during product development, it’s important to acknowledge them and work to prevent them from happening again.

Accessibility issues can be identified during product testing, through user accessibility complaints, or from costs arising from discrimination lawsuits. The important thing is to make the changes needed to improve the next product development process.

This could mean that accessibility features move from the “should have” to the “must have” column in product checklists during design, budgeting, training, development, and testing stages. It could mean that more time and resources are provided to ensure developers are trained, that appropriate software or hardware is purchased, or that adequate testing from accessibility professionals and those with lived experience becomes a priority.

Building digital accessibility into your team’s product development lifecycle does not happen overnight. Recognizing that accessibility is a priority and taking steps to make changes throughout an organization takes leadership, knowledge, and resources.

If you want to remove barriers and create inclusive products for all, Shift Left, start early, and consider how accessible your product is for all possible users, at all stages of the product development lifecycle.

* Footnote: The source is indicative of Canada, but similar percentages (20% or more) apply internationally.

A lot of time and effort goes into the website redesign process. Redesigning your website isn’t a one-time effort; it’s an ongoing process that will continue to shape your web presence for years to come. A well-planned website redesign strategy that considers all aspects of the process is crucial to the success of your redesign and longevity. Many agencies might want to dive right into it, but strategic planning and goal setting is paramount.  

This table of contents provides an overview of all the important aspects you should consider to make your redesign a success. 

1. Planning and Goal Setting 

Define the goals and objectives of the site and create a project plan as if embarking on a client project. Emphasize the call for a plan beyond the launch for further maintenance and content creation. 

During a website redesign, time spent planning is rewarding. These checklist points will help you evaluate the purpose for a redesign, and ensure that the activity prepares you for long-term digital success. 

Develop a business case for the new website. Is it really needed? What do you need to change? How many features do you need? Will the new design help you meet your organization’s goals, objectives, and more? 

Use Google Analytics data to gauge the current website. The data that is collected on how visitors interact with your website will show you why and how they behave the way they do, providing insight on how to manipulate the site to provide a better experience. 

Analyze competitors’ websites for functionality, features, and content completing a competitive analysis allows your organization to understand your strengths and weaknesses and identify industry trends. 

Understanding how your current website performs in terms of views, conversion rates, bounce rates, etc. can help you make decisions to improve the new site. 

Don’t engage a vendor until you determine the functional and technical requirements of the website. These two criteria are important for selecting the right vendor for the project and will help guide the goals and strategy of your new website. 

Knowing your keywords and why people visit your site helps ensure that your SEO strategy is aligned with your website redesign strategy from inception.

Having a clear understanding of your goals, objectives, and desires will help you to plan your strategy in a better way and how your new website needs to address them.

Identifying your USP will help you to leverage the purpose of your new site and maintain a strong brand that will still attract your target audience(s).

2. Selection of a content  management system (CMS) 

A new CMS might be your wingman as you move through the redesign process as it provides better support for your new website’s needs and structure. 

Here are a few things to consider before zeroing in on the new CMS.

  1. Why do you need it?
  2. What are your pressing concerns and will this CMS solve them?
  3. Are the Additional features in the new CMS beneficial to you?

Usage scenarios will help you to understand the CMS and test whether it can be adapted to your daily workflow.

Most open-source software needs to be customized and may require additional support. List out the pros and cons of each CMS and compare them to make an informed decision to suit your organizational needs.

Check out how the CMS performs outside its demo environment with varied conditions and users.  Make sure that it is user-friendly and performs all the tasks that your organization needs without jumping through hoops.

Every software has a downtime but it’s important to know how the vendors respond to it. Find out more about support and technical resources available at your disposal during downtime. 

Always check out references, testimonials, and reviews before jumping the gun.

3. Site structure  

Analyzing your current site and deciding on a new site structure is a complex process. Here is a list of processes that will help you to organize your site’s structure. 

Set up a site structure for organizing content which includes labeling systems, navigation systems, and search functions. 

Consistent organization and URLs ensure a minimum amount of 301 redirects when the new site is launched. 

Documentation always helps, documenting blueprints and wireframes will help both freshers and experienced developers to easily manage the website during downtime or maintenance.

4. Visual design 

Visual design is an essential part of redesigning however, it doesn’t need to be too stressful. Here are some steps for you to create a site that looks great and achieves all your redesign goals. 

An attractive and user-friendly website design is ideal. Make your design unique, but make sure it doesn’t interfere with the user’s experience.

Research and decide on the elements that can be avoided on your website. Here are some things to consider before deciding on design requirements:

  1. Does your site require any specific colors or logos?
  2. Format of each page 
  3. Navigation menu

Once you’ve done that, relax and let the designers get to work. 

Every website should have some level of accessibility! Spending time and money on accessibility now will save you time, money, and the danger of litigation later.

It is difficult to visualize a functioning website. Hence, create page mock-ups in Photoshop or HTML prototypes to give a clear idea of the finished project. Prototypes will help to avoid any ideas that looked good on paper but did not look appealing on screen. 

Before modifying your design for desktop and laptop computers, create and optimize it for mobile devices. Keep in mind that the structure and style of your site should work on all devices, including PCs, tablets, and smartphones. 

Just decreasing your loading time by one second can work wonders, loading time impacts your conversion rates. Optimize your site elements for better SEO and greater user experience.

Create web standards so that the elements of the page such as colors, fonts, page layouts, logo usage, etc. remain consistent throughout the website.

5. Content review

Here are some steps to help you evaluate and optimize your content according to your target audience.

Before deciding on the new content take a look at your content inventory or current content available on your website. Evaluate them and add new content accordingly to build a quality content library.

The next step is to eliminate redundant and outdated content which is not required for your website. This will help you to identify and fill the content gaps in your website.

Assign at least one member of the team to handle only the content development of your organization and ensure it is on track with your redesign timeline.

Get your content approved by the subject matter expert before it goes live on the website. This small check will help you to eliminate any unnecessary content on the website easily.

Ensure that all your content follows the same consistent style on your website. Make sure to document the style guide so it is easy for authors and editors to adhere to these changes seamlessly. 

6. Site development

The next phase of website redesign is the technical part which may be a little challenging for some organizations. Here are some steps to help you in site development.

Templates offer structure to your pages, while style sheets allow you to create a structure with a consistent appearance and feel.

The use of optimized graphics, CSS, and HTML enables for a faster and more enjoyable web experience. To optimize code, use a minifier to remove comments, white space, and other irrelevant characters. Also, make sure that all photos are of the right size for the web (no more than they need to be) and in the right file format.

On-page SEO should be optimized for each page, and all material should have a compelling title and be updated with new information. Check to see if your site is using the proper keywords to draw in your intended audience. You’ll be much easier to find through organic search if you follow this process.

If you want your hard work to pay off at launch, make sure your material is right, relevant, and free of errors. While the content audit is addressed in a previous stage, this step is critical in ensuring that new and migrated content is free of misspellings, broken links, and other problems.

Once your editorial guidelines are in place, double-check that all content follows them. As new content is introduced, set expectations for your team to follow these rules.

Your templates should ideally be ready to use so that content contributors may quickly make modifications or add new content once the site is live. This phase allows you to correct any template mistakes and ensure that your team can properly upload and edit content using them.

Content is king, focus on quality content and take the help of content contributors to add more content to the site.

7. Testing 

The penultimate step of website redesign may seem easy, Step 6 does, however, come with a caveat: testing should occur throughout the whole redesign process, not just at the conclusion. You’ll be able to easily complete the testing process if you perform continuous quality checks during each step of your website’s overhaul.

Put the keyboard down! All site redesign work should be completed before final testing, and the content should be finalized.

Determine the most effective method for test users to submit feedback and report website faults. 

Here are some questions to ask before deciding the process.

  1. Should they email problems as they arise? 
  2. Do you want to complete an assessment at the end? 
  3. Is it possible to have a face-to-face discussion on their findings? 
  4. Choose the method that is most effective for your group.

With a fine-tooth comb, go over every aspect of the site. Examine text thoroughly for correctness, grammar, and spelling, as well as for SEO, accessibility, and overall compliance with editorial style rules and online standards.

Sometimes, what you can’t see has a huge impact on accessibility and SEO. Examine your code for appropriate tags and accessibility attributes, including meta descriptions, titles, alt text, labels, etc. 

Invite visitors with disabilities to test your site’s accessibility while you’re looking at the code. Technical staff should test server performance, security, valid code, and cross-browser and cross-platform compatibility at the same time.

Before going public, give your internal audience a quick glimpse at the progress. This is a great way to get feedback from someone who isn’t involved in the redesign process. The more people who are willing to participate in testing, the better!

Create a list of outstanding items for the redesign team to address after the testing is completed and feedback has been analyzed. You’re ready to go once the changes are finished.

8. Launch and post-launch  analysis 

While the final stage may appear straightforward, there is a lot that goes into launching a website. When it comes to post-launch analysis, this checklist outlines some of the most important tasks to complete in order to preserve the quality of your new site.

Be Careful while adding links and double-check to ensure that all links lead visitors exactly as intended not to the development site.

‘Lorem ipsum’ text is the placeholder content that is used in templates that website developers forget to remove and add original content. Next check for spelling, grammar, and more.

Create an editorial calendar to keep your website updated, new, and on track to accomplish your goals. Maintaining a content publishing schedule is critical, whether it’s updating content on pages or producing a blog post once a week.

As more content is posted to the site, review it for quality regularly. You want to contribute new or updated content, but you also want to make sure it’s accurate and free of errors.

The digital world is a continually changing environment. Meeting with your web staff frequently allows you to discuss current trends and how to develop your site to suit corporate goals and visitor needs.

You should constantly check your site during the redesign process to see if it meets accessibility requirements. Post the launch, don’t allow images that need alt text to be published without it! 

Meet on a regular basis to discuss keyword strategy and analyze analytics to determine what organic search phrases people use to find your site.

Send out surveys, emails, or anything else you can think of to get qualitative feedback from your website users. Learn what customers enjoy and don’t like, as well as what needs to be updated to fit their needs.

Skip to content