How accessiBe works from A-Z (with live website examples), how you can test it, trigger it, and disable it.

Shir EkerlingCEO at accessiBe
Mar 24 2021

Over the last couple of weeks, we encountered a few instances of users attempting to demonstrate issues with accessiBe. In fact, they unintentionally demonstrated how well the solution actually works and showed some understandable misunderstandings in how they believe those websites should work, their functionality, and their features.

accessiBe does a lot of things and understanding it all can often get complex. We wanted to take this opportunity to explain how things work in-depth and explain how to properly test accessiBe if you want to do that by turning it on and off willingly.

But first, here are some of the incorrect “issues” that were raised:

Issue 1 - – A screen-reader user filmed a video in which they meant to show that is fully accessible without accessiBe but isn’t accessible with accessiBe. The user demonstrated many features and functions within the website, from navigating categories using menus and submenu dropdowns to using the search filter, selecting product options, adding to cart, managing the cart, and completing the checkout. What the user did not know that accessiBe was turned on the entire demonstration, and what in fact happened was that it showed how well accessiBe worked by enabling them to do all of the aforementioned actions on the website. Therefore, the website was accessible thanks to accessiBe.

Issue 2 - – A user asserted that accessiBe adds a dozen or more headings to a product specifications table, which makes the screen-reader experience verbose and problematic. In reality, the mentioned table did not have column headers (a heading for every column), rather, it has row headers (a header for every row). To be fair, the user expected a table with column headers, which is the typical kind you would find on this kind of site, but instead, the website had a table with row headers. The way accessiBe did in fact remediate this for an accessible screen reader experience is s identifying that it is actually a row header type of table and made the cells of every row that were visual headings, a row header for screen-readers as well. The fact is that accessiBe made this table accessible and compliant by the book, but the screen-reader user simply misunderstood the type of table they were presented with and that the dozen-plus headers accessiBe created were exactly what should have been there.

Issue 3- – We had a user claim that accessiBe “takes” screen-reader focus. After a Zoom meeting, it turned out that the user ultimately ignored accessiBe’s message to turn the screen-reader mode on, resulting in the repetition of the message every 10 seconds to ensure that the user can browse the website and have an accessible and usable experience. After deliberation, we decided to remove the repetition of the message and instead make the announcement occur only once and include a screen-reader-only fallback button for triggering the screen-reader mode in case the user missed the message.

Issue 4 - – A user complained that they have different issues using even with accessiBe turned on. However, is not an accessiBe customer, and the accessibility solution on that website is not ours. At the time of the complaint, T-Mobile was using a competitor that basically copied our screen-reader Alt+1 trigger message, so it is easy to confuse us with them (more info on that later on this post).

Issue 5 -Lastly, a user claimed that a website (the website’s owners asked to keep the domain in confidence) becomes more complicated to use with accessiBe enabled. When they reached out, our team looked into it and noticed that accessiBe exposed the following elements to screen-reader users: four navigation menus, that each has submenus of dozens of options, two carousels many different links and icons like 4 social media channels, a wishlist, and a shopping cart, and many other elements. All those things weren’t accessible to screen-readers properly, some were even completely ignored. Therefore, when the website became “more complex” this actually meant that the user now had dozens of more elements, functionalities, pages, and options on that website that were completely unavailable to them with accessiBe turned off.

P.S – We also receive viable feedback and bug reports that we fix on an ongoing basis. If you are a user and you’ve encountered an issue or you are unsure, our community support team is more than happy to look into any possible issue. You can reach out to us on any of our social channels.

Not all accessibility solutions are accessiBe. How can you tell?

From time to time, we get support requests or bug reports on websites that use an accessibility solution but turns out that it’s not accessiBe (like the example above).

Since we work closely with users and constantly research the best ways to incorporate functionality, it’s easy for some competitors to copy what we do. accessiBe’s Alt+1 screen-reader trigger message and skip links implementation have been copied by other accessibility solutions that aren’t accessiBe. Although the Alt+1 screen-reader message used to be enough to ensure if the website uses accessiBe or not, unfortunately, that is no longer the case.

However, there’s still a simple way to learn if a website is using accessiBe or another solution. If you are using a screen-reader, simply hit Alt+9 on your keyboard, which will open accessiBe’s interface, and if you hear “Accessibility Adjustments”, then you can rest assured that it is accessiBe. If nothing happens, then that’s how you know that accessiBe is not present on that site. Alternatively, if you are not using a screen-reader, you can look at the bottom of accessiBe’s interface where you’ll see the following text: “Accessibility solution by accessiBe”.

How to turn accessiBe ON and OFF for testing purposes or otherwise

There are several different triggers that cause accessiBe to automatically activate ‘accessible mode’ even if a user did not intentionally trigger it. For example, if a keyboard user navigates the website using the Tab key, accessiBe automatically turns on the accessible mode so the user can keyboard-navigate without a problem.

Another trigger is using accessiBe’s ‘skip links’, either with or without a screen-reader. The skip links appear at the top of the page right when a user starts navigating using the Tab key or the arrow keys with a screen-reader. The purpose of the skip links is to let users quickly and easily skip blocks and get to important sections of the page like the menu, the content, and the footer, without having to tediously navigate element by element. When a user clicks one of the skip links, the accessible mode turns on automatically.

The last trigger (other than the Screen-Reader/Keyboard-Navigation profiles inside the accessiBe interface) is clicking the Alt+1 keyboard combination. When a screen-reader user enters a website with accessiBe, they hear the message “To use this website in screen-reader mode, click Alt+1 (or Option+1 for MacOS)”.

Turning accessiBe/accessible mode off: to turn accessiBe’s adjustments off (e.g., get out of screen-reader mode), simply click Alt+8. The page will refresh and the screen-reader mode won’t turn on. Clicking on the “Reset Settings” button inside of the accessiBe interface is another way to turn all adjustments off.

Completely removing accessiBe: turning screen-reader mode off doesn’t mean that it won’t turn on again using the triggers mentioned above. Therefore, if the purpose is to test the page like accessiBe was never there, Alt+0 will completely disable and remove accessiBe from the page. Hitting Alt+0 again brings accessiBe back to the page (this combination has a toggle functionality).

So, what does accessiBe actually do? How does it work?

Below you’ll find simple, short, and straightforward explanations to very complex processes that accessiBe applies. We’ve tried to be as non-technical as possible with the explanations and simplify them. If you’d like further explanation, don’t hesitate to reach out and ask!

For screen-readers and keyboard users:

Before diving into specific adjustments such as links, menus, icons, forms, and others, it is important to understand how it works in general. When a website implements accessiBe, a background process starts to analyze the website with every visitor session. The analysis includes processing the website’s stylesheets and HTML, alongside its behaviors like where people click, where they put their mouse, what changes on the page after interacting with a specific element, and much more.

The purpose of the analysis is to first learn the purpose and function of the website’s elements, and the connections between them. Then, to learn where to apply the necessary ARIA attributes and code modifications, according to the results, so the browsing session is accessible using the keyboard and/or a screen-reader. We call this a “Contextual Understanding” process.

Links: accessiBe scans every empty or insufficient link (for example, “Read More”) and it adds a screen-reader-only text that describes its destination. For example, icons that their purpose is represented only by an icon, like Facebook’s logo, a shopping cart icon, or a magnifier icon to indicate a link to the search page. Additionally, links that open in a new tab receive a screen-reader text that indicates this, as well as a visual indicator.

A screenshot showing a code example of accessiBe describing a link to a company's Twitter page that is represented visually only as an icon

Buttons: accessiBe identifies elements that function like buttons but aren’t coded as such like links and spans (which are just text elements). To remediate them, accessiBe tags them as buttons using role=button and ensures that they can get keyboard focus and keyboard clickability, which they don’t have by default. In case these elements don’t have text but are being represented using an icon, accessiBe will identify the icon and will provide a text purpose of the button just like it does with link-icons as explained above.

A screenshot showing a code example of accessiBe describing a cart button to screen-reader. The cart was represented visually only by a cart icon.

Landmarks: accessiBe identifies and “tags” important page landmarks such as navigation, search, footer, carousels, main content, and others. accessiBe does that by using the role attribute (role=main, role=contentinfo, role=navigation, etc.) with the right context, and an aria-label with an accessible name like “Main Menu”, “Support Menu”, etc.

A screenshot showing a code example of accessiBe identifying a footer landmark that isn't coded as contentinfo/footer and provides the right ARIA implementation

Graphics: accessiBe scans every image that lacks an Alt text (accessiBe does not override Alts that are provided by the website) and processes them using an AI engine that creates an alt from the objects, scenery, and the text of the image. For example, an image of people playing ball on the beach with the text “50% off beachwear” will receive an alt text equal to “50% off beachwear. A group of people playing football on the beach”.

A screenshot showing a code example of accessiBe's AI describing providing the following alt to an image:

Menus: as part of the analysis process, accessiBe learns which of the elements are menus and their purpose (main menu, page menu, etc.). Then, accessiBe will “tag” that information for screen-readers using the role and the aria-label attributes. Dropdowns or submenus receive full keyboard functionality and are announced using the aria-haspopup attribute. Submenu states are announced using the aria-expanded attribute that equals to ‘true’ or ‘false’ depending on if the submenu is expanded or collapsed.

A screenshot showing a code example of accessiBe identifying and a main menu as main menu navigation region + exposing and remediating the navigation submenus

Forms: accessiBe identifies the purpose and the validations of all form elements and labels them accordingly for screen-readers using the aria-label and the aria-invalid attributes. Additionally, the validation status of each field is announced to screen-readers using the aria-invalid attribute. If the form submission is failed due to a validation error, accessiBe takes the user directly to the first field that should be fixed while announcing the errors. If the form is submitted successfully, this also is communicated to screen-readers.

A screenshot showing a code example of accessiBe making a form field accessible for screen-reader users

Headings: accessiBe learns which of the textual elements functions as a heading, including and especially elements that appear visually on the page as a heading but aren’t coded as such as span, div, or strong. Then, it tags them as headings using the role=heading and the aria-label attributes. To ensure proper screen-reader experience, accessiBe orders the headings with a proper hierarchy based on their importance (heading level 1 to 6).

A screenshot showing a code example of accessiBe identifying a visual heading that isn't coded as a heading, and marking it as a level 3 heading

Tables: there are 2 types of tables that accessiBe remediates. (1) a layout table, which accessiBe negates standard screen-readers-table functionality for and (2) a table without coded column or row headers but that does include headers visually, which accessiBe marks as table headings for screen-readers and enables standard table-cell navigation.

A screenshot showing a code example of accessiBe identifying column headers and marks them for screen-readers

Popups and modals: when popup/modals appear, accessiBe identifies this in real-time, and immediately communicates the appearance of such popup to screen-readers using the aria-modal=true and the role=dialog attributes. Additionally, accessiBe immediately moves the focus into the popup and locks the navigation both for tab navigation and for screen-reader users to inside the popup so users don’t escape it unintentionally and lose orientation. Lastly, when a popup is active, accessiBe enables users to close/remove it by both the Esc key and a close button.

A screenshot showing a code example of accessiBe identifying an active popup and makes it immediately accessible for screen-readers

Other than the list above, there are many other adjustments and remediations that accessiBe applies but these are less complex and more individual. For example, accessiBe can learn a rating of a product from the visual star icons and provide a screen-reader description for that. We hope that the explanations above provide a bit more color to how accessiBe works!

For users with low vision, epilepsy, cognitive disorders, and more:

How it works: websites that are powered by accessiBe include accessiBe’s accessibility interface which is designed to cover the accessibility requirements relating to the UI, the design, and the readability of websites. By using the interface, low vision users, users with cognitive disabilities, epileptic users, and others can modify a website’s design to meet their individual needs specifically.

To do that, users can choose a pre-built disability profile, such as the “Vision Impaired Profile”, and the website’s UI and design will be immediately adjusted to accommodate their disability for an easier and safer browsing experience. Alternatively, or in addition to the profiles, users can choose to enable different adjustments, such as to increase font sizes, change color contrasts, stop animations, and much more.

A few examples of how users with disabilities use accessiBe’s interface:

  • Vision impairments often require a minimum threshold of contrast ratio between text and background to be able to see it properly. Using the interface, users with such a disability can select to browse the website in the Vision Impaired Profile or to enable a Dark Mode or a Light Mode that both usually meet WCAG success criteria.
  • Users with cognitive disabilities often have a hard time focusing on the essential parts of a website due to distractions and noise such as images, videos, popups, animations, and sliders. The Cognitive Disability Profile reduces distractions to a minimum and provides additional adjustments to help users concentrate. These adjustments include highlighting headings and interactive elements, stopping animations, and more.
  • Users with epilepsy are often at risk of having a seizure due to flashing GIFs, animations, and colors. An epileptic user can enable the Seizure Safe Profile which will immediately stop all flashing animations and will reduce risky hues to eliminate the risk of seizures.
  • People with degrading eyesight may find a website’s texts or even layouts to be too small, too narrow, or too crowded. By using the interface, users can space out the height between rows, the margins between letters, increase font-sizes, and even scale the entire layout and content of the site, until it fits their specific needs.

Of course, there are dozens of use cases and examples of how people can utilize the accessibility interface. These examples provide only a taste of how it works.

Below, you’ll find a list of all of the interface’s available adjustments grouped by category:

Accessibility profiles

  • Seizure Safe Profile – this profile enables users with epilepsy to use the website safely by eliminating the risk of seizures that result from flashing or blinking animations and risky color combinations.
  • Vision Impaired Profile – this profile adjusts the website so that it is accessible to the majority of vision impairments like cataracts, glaucoma, and degrading eyesight.
    Cognitive Disability Profile – this profile provides various assistive features to help users with cognitive disabilities such as autism, dyslexia, CVA, and others focus on the essential elements of the website more easily.
  • ADHD Friendly Profile – this profile significantly reduces distractions and noise by providing a mask to help people with ADHD and neurodevelopmental disorders browse, read, and focus on the essential elements of the website more easily.
  • Blind Users Profile (Screen-readers) – this profile adjusts the website to be compatible with screen-readers such as JAWS, NVDA, VoiceOver, and TalkBack. A screen-reader is software that is installed on the blind user’s computer and smartphone, and websites should ensure compatibility with it.
  • Keyboard Navigation Profile (Motor-Impaired) - this profile enables motor-impaired persons to operate the website using the keyboard Tab, Shift+Tab, and the Enter keys. Users can also use shortcuts such as “M” (menus), “H” (headings), “F” (forms), “B” (buttons), and “G” (graphics) to jump to specific elements.

Content adjustments

  • Font sizing – users can increase or decrease the size of the fonts.
  • Font readability – users can change the font type of unreadable fonts like hand-writing fonts, to their system’s default font that is readable to them.
  • Text magnifier – users can view any on-page text in a separate, bigger text box.
  • Title highlight – users can select to emphasize all titles on the page with a big blue boxed border for better orientation.
  • Link highlight – users can select to emphasize all links on the page with a big, orange-boxed border for better orientation.
  • Content scaling – users can scale the entire layout of the page and proportionally increase the size of all elements of the web page.
  • Line height spacing – users can adjust the space between lines in all of the website’s sentences if these appear too close or on top of each other.
  • Content alignment – users can change the alignment of the website’s texts to left, right, or to the center.

Color and display adjustments

  • Dark contrast – users can choose to use the website in a dark color scheme that provides a very high background and foreground contrast ratio.
  • Light contrast – users can choose to use the website in a light color scheme that provides a very high background and foreground contrast ratio.
  • High contrast – users can increase the contrast and vibrance of the page.
  • High saturation – users can increase the color saturation of the page.
  • Low saturation – users can decrease the color saturation of the page.
  • Monochrome – users can eliminate all page colors and make it monochrome.
  • Text colors – users can choose a color that they easily see and set it to all texts.
  • Title colors – users can choose a color that they easily see and set it to all titles.
  • Background color – users can choose a color that they easily see and set it to all backgrounds.

Orientation adjustments

  • Reading Guide – users can enable a guide that follows their mouse and helps focus on the essential content of the page.
  • Reading Guide – users can enable a mask that desaturates the parts of the website that are not currently focused, thus reducing distractions and noise.
  • Image’s display – users can choose to remove ‘background noises’ such as images and background images to focus on the content of the page.
  • Online dictionary – users with cognitive disorders are able to look up phrases, slang, concepts, landmarks, and people that are mentioned on the web page.
  • Sound Control – users with hearing devices can choose to automatically mute all automatic sounds that are playing on the site (automatic videos, etc.)
  • Quick navigation – users are able to go to any of the most important pages of the site from a single place without needing to go through all various website menus.
  • Focus highlight – users can choose to double the visual orientation ring appearing when focusing on an interactive element.
  • Hover highlight – users can choose to double the visual orientation ring appearing when the mouse hovering an interactive element.
  • Mouse cursor - users are able to change the browser’s default small cursor with either a big black one or a big white one, for better orientation.

Find out now if your website is ADA  & WCAG  Compliant