We want all learners to interact as fully as possible with the courses you create in Rise. We know it’s important to you as well. That’s why accessibility is a critical part of our roadmap. Below we’ve put together a journal of the work we’ve done so far—feel free to read it all or jump right to an entry that catches your eyes. We’ll update this often as we continue our accessibility journey.

Did you know—"a11y" is a numeronym created to help raise awareness of accessibility issues and causes. You can read more about the history of a11y over at the A11Y Project site.

Being a human-centered organization, we take it seriously when our customers reach out about accessibility issues. Recently, someone let us know that "bouncy" animations in Rise quizzes were causing them distress. Those animations are meant to keep the quiz in an optimal viewing spot on the screen but, depending on scroll view and browser size, they can become overly pronounced and possibly trigger serious physical reactions such as vertigo.

We acted immediately, targeting the quiz animation, as well as the pulsing animation associated with unvisited labeled graphic items (pulsing animations can also cause distress). We determined that the quickest way to release a solution was to add the prefers-reduced-motion css media query to them. This way, when a user has reduce motion or remove animation settings enabled on their device, the animation doesn't process.

We take every accessibility issue seriously, but when they can also cause physical harm, we can't afford to wait. We addressed this issue in less than a month and are actively exploring ways we can globally support reduce motion settings.

The improvements we made in this update follow these WCAG criteria: Animation from Interactions (Level AAA) 2.3.3

It's hot outside, so why not chill out with some cool Rise accessibility news!

This handy new feature (found in Theme > Color) lets authors ensure that their training content meets accessible color-handling requirements for learners with low vision at a 4.5:1 ratio.

From left, Auto, Dark, and Light contrast settings

You can manually select light or dark contrast but the real a11y win is when you select Auto. This enhances cover pages, lesson headers, and navigation buttons. As you can see in the image above, when selected, light text automatically appears on dark colors and vice versa.

We've also made improvements to block elements that are tied to theme color (like the bullets in bulleted lists). Just like the text in lesson headers and navigation buttons, when a graphic element in a block uses the theme color and also uses a symbol or text, the contrast is automatically adjusted to preserve readability.

Cover photos also go a contrast glow-up recently with the addition of a light/dark overlay. Select Light to display dark text on a lightened image…

…or Dark to, you guessed it, show light text on a darkened image.

You can even adjust the overlay percentage manually to increase or decrease the contrast.

Finally, we've made a slight but important adjustment to our black text. It's now "true" black (that's hex code 000000 for all you graphic designers). This helps improve accessibility conformance for all your training.

The improvements we made in this update follow these WCAG criteria: Contrast (minimum) 1.4.3 (Level AA), Non-text Contrast 1.4.11 (Level AA)

Spring is just around the corner and we're charging forward into sunny days and warmer temperatures with three major accessibility updates.
​

Screen reader announcement labels are hidden labels used by, you guessed it, screen readers to describe user-interface elements like buttons and links. Translating these along with your other labels is essential to ensure maximum accessibility for all learners.

These labels have always existed in Rise, but there hasn't been a way to translate them. That's changed with the new Screen Reader Announcement tab. Now, you can easily modify accessibility labels in Settings just like any other label. Even better, when you export your labels for translation, screen reader announcement labels are marked with an a11y tag so that they're easy to find.

Good news! Process blocks are now WCAG 2.1 conformant! We took special care with process blocks to ensure a smooth learner experience. If you're interacting with the block via keyboard, you can logically tab your way through the interface. The focus remains on the Next button in interactions, and screen readers announce the title for the current step. That way, learners can decide whether to tab through and interact with the step content or advance to the next process step.

We also improved accessibility for quote blocks. The keyboard experience for quotes with links has been improved. It no longer focuses on the quote multiple times (previously, you would navigate to the displayed version and the version available to screen readers). This enhancement lets learners interact with the block via screen reader without extra chatter.

The improvements we made in this update follow these WCAG criteria: Keyboard 2.1.1 (Level A), Focus Order 2.4.3 (Level A), Headings and Labels 2.4.6 (Level AA), Name, Role, Value 4.1.2 (Level A)

What's better than having one flashcard block accessible? Having both flashcard blocks meet accessibility guidelines!

In October, we made improvements to the flashcard grid block but were still working on its block-mate. We've now brought those improvements to flashcard stack blocks so that they're also WCAG 2.1 conformant. Like grids, stacks have better screen reader support and are fully keyboard navigable.

When we started this effort, we quickly discovered that there weren't any accessible flashcard designs out there. So we made our own. Robert Pearce, one of our senior software engineers, developed a solution, then partnered with Microsoft's accessibility experts to hone the design. After extensive testing, we were able to bring this innovative solution to Rise. We hope this effort will help lead the way for other organizations.

We've made other, non-flashcard, improvements to Rise accessibility as well.

The improvements we made in this update follow these WCAG criteria: Meaningful Sequence 1.3.2 (Level A), Contrast (minimum) 1.4.3 (Level AA), Non-text Contrast 1.4.11 (Level AA), Keyboard 2.1.1 (Level A), Focus Order 2.4.3 (Level A), Focus Visible 2.4.7 (Level AA), Name, Role, Value 4.1.2 (Level A), On Input 3.2.2 (Level A)

If you guessed from the title that this update would be about flashcards, you get a gold star!

Flashcard grid blocks are now WCAG 2.1 conformant, with improved keyboard and screen reader support. Screen readers announce when you're on a flashcard flip button, and there's a helpful mouse hover tooltip that's accessible for keyboard-only users. You can also highlight and copy flashcard text. While we were at it, we resolved an issue where the flip button sometimes overlapped the scrollbar in Windows.

Also, with the new themes feature, we changed how we display text on flashcards, looking at how much space characters occupy rather than just how many characters there are. It makes for a cleaner experience that's easier to read.

How good are the new flashcard grid block improvements? Our Fable tester gave the new flashcard block a 100% score! They said that flashcards were easy to understand and navigate and added that the screen reader experience was "a delight."

The improvements we made in this update follow these WCAG criteria: Meaningful Sequence 1.3.2 (Level A), Sensory Characteristics 1.3.3 (Level A), Contrast (Minimum) 1.4.3 (Level AA), Keyboard 2.1.1 (Level A), Focus Order 2.4.3 (Level A), Focus Visible 2.4.7 (Level AA), Name, Role, Value 4.1.2 (Level A)

It's been a busy summer! So busy, that we didn't have a chance to catch our breath and let you know what was going on in regards to accessibility in Rise 360. Let's fix that with a rundown of everything we've accomplished since May!

Earlier this month, Rise got a major redesign! In addition to new features like premium content, we totally revamped the Learn tab. The redesign reflects our commitment to accessibility-forward development. We want to incorporate accessibility practices into new features as part of the design process, not as an afterthought.

The whole onboarding experience and course carousel are fully accessible, with proper heading levels and a skip link. The Learn tab is fully landmarked and meaningful for those using screen readers to navigate. While we still have work to do, Rise is now more accessible than ever.

But don't just take our word for it. Fable, a group that hires individuals with disabilities to test and offer feedback on sites, gave the new Rise onboarding process an incredible accessibility usability score of 98%!

Interactive blocks can be a challenge for screen readers to parse properly. That's why we went back and greatly improved the screen reader performance for timeline blocks. It's a much cleaner experience overall. Timeline blocks are still announced as a group, but now it's a semantic list, because essentially it's a series of events. Even better, each card in the timeline block isn't announced separately and the extra tab stop has been removed; this caused needless chatter. For visual learners, timeline cards now have discernible borders in Windows High Contrast mode.

In addition to improving the experience of interactive blocks, here's everything else that we've done this summer. Take a deep breath, it's a lot!

The improvements we made in this update follow these WCAG criteria: Captions (Prerecorded) 1.2.2 (Level A), Non-text Contrast 1.4.11 (Level AA), Keyboard 2.1.1 (Level A), Headings and Labels 2.4.6 (Level AA)

No, really, it is! After all, when you take a quiz or answer a knowledge check, knowing why an answer is right or wrong is nearly as important as getting it correct in the first place. In this update, we've improved feedback performance in screen readers so that it's clear to users when they're in the feedback field. We've also improved functionality for those using Android Talkback, allowing them to interact with the feedback text.

Oh, and one quick dip into the world of Windows high contrast mode (which we talked about last week), we've made it so that the continue block's border and that bullets in the bullet block are visible as expected.

The improvements we made in this update follow these WCAG criteria: Non-text Contrast 1.4.11 (Level AA), On Input 3.2.2 (Level A), Error Identification 3.3.1 (Level A)

There's a very clear rule when it comes to accessibility and non-text elements in an interface: they must have at least a 3:1 contrast ratio between the element and the background. Now, there are contrast checkers and utilities that we use to help ensure the Rise interface meets that ratio. But when users employ something that fundamentally changes baseline contrast, like Windows High Contrast mode, it gets harder to maintain that golden ratio.

Harder. But not impossible.

In this update, we've continued the work started earlier this month, ensuring that interface elements are easily visible, even if you're employing a high-contrast system setting.

In Windows High Contrast mode, we adjusted the following items so that they're not washed out in light or dark contrast modes.

For the following interface elements, we increased or, in some cases, eliminated hover contrast:

We also removed an unnecessary tooltip that appeared when hovering over the lesson progress icon.

And this is just the beginning. We're dedicated to ensuring that everyone can easily use Rise, no matter how they meet us. We'll be back soon with even more improvements!

The improvements we made in this update follow these WCAG criteria: Non-text Contrast 1.4.11 (Level AA), Headings and Labels 2.4.6 (Level AA), Focus Visible 2.4.7 (Level AA)

There's a point when you're working on something, anything, where you've got a few big parts squared away but haven't yet started the next round of big changes. You want to move forward, but there are smaller bits that you need to get just right before you do.

We've been busy for the past month fine-tuning accessibility in Rise, getting the small things just right and the finer details dialed in before moving on to the next big thing.

The improvements we made in this update follow these WCAG criteria: Non-text Content 1.1.1 (Level A), Non-text Contrast 1.4.11 (Level AA), Headings and Labels 2.4.6 (Level AA), Focus Visible 2.4.7 (Level AA)

This week's changes focus on improving the user experience and making it easier for everyone to access their courses, however they're interacting with Rise. Here's what we've been up to in these first couple of weeks of the new year.

The improvements we made in this update follow these WCAG criteria: Info and Relationships 1.3.1 (Level A), 1.4.10 (Level AA), Non-text Contrast 1.4.11 (Level AA), Focus Order 2.4.3 (Level A), Reflow Localization and Focus Improvements

And we're back! It's been nearly a year since our last update but that doesn't mean we haven't been working on accessibility. In fact, our developers have been working behind the scenes to bring a focus on accessibility to all of our new and upcoming features.

Along those lines, we have one new enhancement and three new fixes that help us get a little closer to our goal of an inclusive Rise experience.

And we're just getting warmed up. Watch this space for more details on our accessibility plans for 2022.

The improvements we made in this update follow these WCAG criteria: Contrast (Minimum) 1.4.3 (Level AA), Focus Order 2.4.3 (Level A), Language of Page 3.1.1 (Level A)

Labeled graphic blocks are a great way to bring visual flair to your courses and let learners explore at their own pace. However, especially if paired with a white background, the default labeled graphics markers need more contrast to meet accessibility guidelines.

That’s why authors now have the ability to modify their markers with a handy color picker. Found in the labeled graphic block settings, the color picker lets you quickly change the color of all your markers either by entering the hex code, using the brand color, or selecting a custom color of your choice.

Other improvements to the labeled graphic block include:

With these upgrades in place, we can now say that the labeled graphic blocks are 100% accessible!

The improvements we made in this update follow these WCAG criteria: Non-text Content 1.1.1 (Level A), Info and Relationships 1.3.1 (Level A), Descriptive Labels 2.4.6.b (Level AA), Name, Role, Value 4.1.2.a (Level A)

In the past few weeks, we improved screen reader responses for quizzes and knowledge checks. For multiple choice and multiple response questions, it’s obvious when learners enter list elements. Additionally, keyboard navigation makes it clear when a choice has focus. Answer reviews and reveals are now accessible to screen readers, and feedback announcements are more intuitive. The quiz results page follows a logical order with fewer distractions, making it easier for learners to understand their results.

The improvements we made in this update follow these WCAG criteria: Info and Relationships 1.3.1 (Level A), Meaningful Sequence 1.3.2 (Level A), Keyboard 2.1.1 (Level A), Focus Order 2.4.3 (Level A), Focus Visible 2.4.7 (Level AA), Name, Role, Value 4.1.2 (Level A)

Course cards in My Learning and the library now announce all the elements within the course card rather than just announcing the card as a single unit. Those elements are presented in a logical order. For example, even though the overdue status and favorites button are listed above the course link visually, the link is announced first since it’s the most important thing on the card.

Depending on whether you’re browsing the My Learning list or the library, you can navigate to specific elements on each course card when using a screen reader. These include:

What’s the favorites button? On library course cards, there’s a heart icon that users click to save the course to their list. Even though it doesn’t look like a button, it functions like one. We made changes behind the scenes so you can toggle it via keyboard navigation just like any other button. We also improved screen reader support so the button announces itself as “Save to My List” plus its selected or deselected state. This way, users know exactly what will happen when they toggle the button.

Speaking of screen readers, the courses in My Learning are read as a list. This makes it even easier for visually challenged users to explore their courses.

We also made changes to the Global Search button. The magnifying glass icon in the upper right corner, next to the user icon, now opens the search dialog as expected when you navigate to it and press the Enter key. It also announces itself as “global search” rather than just “search” so users know they’re searching the entire Rise site.

The improvements we made in this update follow these WCAG criteria: Info and Relationships 1.3.1 (Level A), Meaningful Sequence 1.3.2 (Level A), Contrast (Minimum) 1.4.3 (Level AA), Keyboard 2.1.1 (Level A), Focus Order 2.4.3 (Level A), Name, Role, Value 4.1.2 (Level A)

Alternative text (alt text) is a key element of accessibility. With the multitude of image-based blocks in Rise, we made sure you can add alt text to your images and that screen readers announce that text elegantly.

First, we went through our image blocks and verified that alt text is only read once by screen readers. This includes:

If there are images in these blocks that don’t have alt text, screen readers ignore the tag and just announce them as images or read the file name.

To wrap things up, we addressed click-to-zoom images. Screen readers now announce a zoom button for images. The interface won’t be any different for sighted users but ensures those who use screen readers have a comparable experience. When users zoom in on an image, screen readers announce the alt text associated with it for context.

Additionally, we added elements to the Rise interface to make it even clearer what happens when you interact with UI elements.

The improvements we made in this update follow these WCAG criteria: Info and Relationships 1.3.1 (Level A), Meaningful Sequence 1.3.2 (Level A), Parsing 4.1.1 (Level A), Name, Role, Value 4.1.2 (Level A)

Most people don’t give a second thought to color contrast and how it affects design. But it has a marked effect on how you and your learners approach Rise.

If the contrast between elements is too stark, like black checkboxes on a white background, it can make things feel a little basic. Conversely, if the contrast is too subtle, like light grey boxes on a white background, it becomes harder for learners with low vision to experience the full impact of your content.

That’s why we’ve gone through and closely examined the color contrast and opacity of the following elements and made adjustments. They’re more accessible, while still ensuring your learners enjoy the high-end design they’ve come to expect from Rise. Here’s what we’ve done to improve contrast in Rise:

The improvements we made in this update follow these WCAG criteria: Contrast (Minimum) 1.4.3, Non-context Contrast 1.4.11 (Level AA)

We made the learning path overview (shown above) even better than before. We already enhanced course cards, but this time we focused on improving screen reader support for the learning path overview.

A large part of making a site screen reader accessible is consistently and properly labeling elements based on what they do, rather than what they look like. With that in mind, we started at the top with the learning path overview header.

The Start Learning Path button in the image looks like a button but, functionally, it isn’t. There’s no “on/off” toggle status. When you click it, you’re taken to the first course in the learning path, therefore, it functions like a link. So now, when a screen reader encounters the Start Learning Path/Continue Path “button,” it describes it as a link element. That way the functionality is clear and learners know what will happen when they interact with it.

Additional overview header improvements include:

Since the learning path overview shares a similar structure to the course overview, we leveraged the work we did there and applied it here.

Additionally, screen readers now read the entire author list, even if part of that list is hidden behind a Show More button. They’ll also ignore the alt text for author avatars since those are decorative elements.

We similarly improved the topic list. Rather than being announced as graphic elements, screen readers now announce the topic list as, well, a list.

The improvements we made in this update follow these WCAG criteria: Info and Relationships 1.3.1 (Level A), Meaningful Sequence 1.3.2 (Level A), Identify Purpose 1.3.6 (Level AAA), Content on Hover 1.4.13 (Level AA), Keyboard 2.1.1 (Level A), Link Purpose (link only) 2.4.9 (Level AAA)

After the course overview, we focused our attention on the sidebar. The sidebar is more than just a menu. It displays a list of lessons and sections and also functions as a results box when you use the search bar. We wanted to make it even easier to access the information in the sidebar when using just the keyboard or a screen reader.

When you use the Tab button to navigate, you should only be able to interact with the elements displayed on the screen. We made sure that you can’t press Tab to access lessons hidden under collapsed section headers in the sidebar.

Also, when the sidebar itself is hidden completely by the course author, we found that you could still tab to the search field. Not only is that not accessibility compliant, but it can bypass author intent. We changed this and now you can’t access the search field if the sidebar is hidden.

Speaking of restricted course navigation, if the learner is required to take a quiz to continue in a course, there are several visual cues, including a pop-up tooltip. Those tooltips now display when a user tabs to a lesson they can’t yet access.

The improvements we made in this update follow these WCAG criteria: Content on Hover 1.4.13 (Level AA), Keyboard 2.1.1 (Level A), Focus Order 2.4.3 (Level A), Name, Role, Value 4.1.2 (Level A)

Since the sidebar does so much, we wanted to make sure that screen readers properly announced each section. We labeled each individual portion of the sidebar with its true function, rather than having the entire element announced as a “menu.”

Searching from the sidebar needed additional tweaks to make it work better with screen readers. This was tricky. After all, we’re taking a section of the interface you usually use to navigate and turning it into something completely different—a search field and results list. Now, screen readers announce if the sidebar is displaying search results or the course outline.

We reworked the icons as well. The X that closes the search field was announced simply as “X,” so we gave it more context. Now, screen readers announce that button as “Close the Search Form.” Much more descriptive! We also hid the magnifying glass icon from screen readers since it’s purely decorative.

The improvements we made in this update follow these WCAG criteria: Non-text Content 1.1.1 (Level A), Identify Purpose 1.3.6 (Level AAA)

Progress Indicator

As you scroll through a lesson in Rise, one thing happening in the periphery is that the “progress pie” fills up in the sidebar as you reach completion. For quiz lessons, you can glance at the sidebar and see if you passed or failed based on their icons. They’re nice visual reminders when you return to a course of how far along you are and how you’re doing.

Screen readers now announce the lesson title as well as the current recorded progress as a percentage. If it’s a quiz lesson, the screen reader announces if you passed or failed that quiz previously.

And to support our sidebar labeling effort, all of these lessons are now listed as buttons with the necessary pressed and unpressed states.

The improvements we made in this update follow these WCAG criteria: Non-text Content 1.1.1 (Level A), Identify Purpose 1.3.6 (Level AAA)

Sidebar Control

Learners can collapse and expand the sidebar using the menu icon (☰) in the upper left corner of the lesson content. And now, screen readers announce the icon's function so visually impaired learners know what it does: “Open/Close Lesson Sidebar.”

The improvements we made in this update follow these WCAG criteria: Identify Purpose 1.3.6 (Level AAA), Name, Role, Value 4.1.2 (Level A)

One of the great time-savers in Rise is the ability to create learning paths from multiple courses. To interact with that feature, learners use the learning path overview. And on that overview, we have course cards, as shown below.

An orderly grid of cards is visually appealing, but screen readers have difficulty interpreting it. So we took the logical step of allowing screen readers to see this grid of cards as a numbered list.

Next, to make our new list of courses more useful, we tell the screen reader to ignore certain visual elements, like the course card cover photo and the number icon, so that the card information is presented clearly and in a logical order: title, course length, due date (or completed date), and progress. If a course can’t be accessed yet (because progress requirements haven’t been met), screen readers announce the tooltip that displays.

The improvements we made in this update follow these WCAG criteria: Info and Relationships 1.3.1 (Level A), Identify Purpose 1.3.6 (Level AAA), Content on Hover 1.4.13 (Level AA), Keyboard 2.1.1 (Level A), Link Purpose (link only) 2.4.9 (Level AAA)

With this update, we improved accessibility for the course overview that displays whenever you launch a course.

While Rise already supports keyboard navigation, we made refinements so it’s even better. One example of this is the persistent user profile menu in the upper right corner of the screen. This avatar is available in every main tab of the Rise experience. Clicking it displays a menu where you can access your user profile, get help, or sign out of Rise.

We improved the functionality so you can’t tab into those menu options when they aren’t visible. Now, the menu is accessible only if you tab to the avatar and press Enter or the spacebar to interact with it.

The improvements we made in this update follow these WCAG criteria: Keyboard 2.1.1 (Level A), No Keyboard Trap 2.1.2 (Level A), Keyboard (No Exception) 2.1.3 (Level A), Focus Order 2.4.3 (Level A)

When you visually navigate an interface, it’s easy to take for granted the elements that provide information but aren’t crucial to understand the content. For example, on the course overview page, we have headers for things like title, description, and course outline, which convey the most information:

But there are also elements that give you “at a glance” information like course duration, author, and completion requirements.

That information gives you a full understanding of the course but doesn’t have header labels. We added those labels so it’s easier to navigate the course overview with a screen reader.

Another important part of the course requirements section is the status icon, letting you know if you completed a course and passed the quiz (if there is one). We streamlined this element so screen readers don’t announce the icons if they’re not in use. And when they are in use, we do a better job of describing their state.

We made a number of additional screen reader enhancements as well:

The improvements we made in this update follow these WCAG criteria: Bypass Blocks 2.4.1 (Level A), Headings and Labels 2.4.6 (Level AA), Name, Role, Value 4.1.2 (Level A)