Our goal at Grasple is to help everyone learn statistics, mathematics or any numeric related knowledge. This also means our platform must be easy to use for any learner who wants or needs to learn these topics.
Therefore we started a thorough investigation into how accessible our platform since the summer of 2024. Based on that we concluded we needed to changes in our platform to ensure that learners with different abilities can use Grasple for learning. In this article you can read about our progress on this and why we made certain updates in the platform to achieve this.
Approach
Our approach is the following: we use the WCAG 2.2 Level AA requirements as baseline for how we are making our platform accessible. This means that at the end of this project, the platform should be fully WCAG 2.2 Level AA compliant and not just partially compliant (as it is at the time of writing).
We use resources and tools available to assess this and determine solutions to fulfil each criteria from the requirements. We are currently rolling out updates (see below) and will continue to do so until beginning of 2025 to become fully compliant.
After this we will use user testing and feedback to continuously improve our platform. If you (or your university) are interested in testing and providing feedback, please reach out to us since we are happy to receive feedback on how easy to use the platform is for different users.
This document will be updated regularly such that is reflects the current state and approach of our efforts.
Updates
Color contrast
We updated our color palette we use in our application to make sure that the contrast of how these colors are used are sufficient according to the WCAG 2.2 AA requirements.
We identified the following usages of color:
background color with longer dark/light text;
background color in buttons with dark/light text;
icon colors on top of dark/light background;
icon colors on top of colored background.
We updated all the colors to ensure we have sufficient contrast. This means that all colors except for the light/dark text colors are updated to ensure the contrast ratio is higher.
There is one color not yet contrasting enough, this will be updated in a later update and will be reflected in this article.
These updates are based upon the following criteria from the WCAG 2.2. AA Requirements:
Skip to main content
To help users out to get to the main content quickly when navigating with a keyboard, we added a Skip to Main content button which skips over the fixed navigation bar at the top.
This updates is based on the criteria 2.4.1 Bypass Blocks from the WCAG 2.2 AA Requirements.
Unique names/labels for repeatable elements
On our exercise pages we can have multiple questions which have the same name programmatically (e.g. "check-answer-button"). To ensure it is easy to differentiate between these when using a screenreader we updated these names to be unique per question (e.g. "check-answer-button-for-question-1").
Improved Keyboard Control
To make sure the whole learning platform can be operated with keyboard only, we updated two parts which we identified as unaccessible for keyboards:
we made sure the dropdown in the navigation bar is easy to operate with a keyboard only;
we ensures that the arrows on the left and right side of the screen can be operated using the keyboard;
These updates are based on the criteria 2.1.1 Keyboard from the WCAG 2.2 AA Requirements.
Indicate website language programmatically when changed by user
A website can indicate the language of the website in their "lang" attribute in the html tag. We did this by indicating the language "English" (our default language), but did not change this when the user changed the language in the application.
We now update this value based on the language the user is using, such that screen readers can use this to inform the user about the language currently used.
This update is based on the criteria 3.1.1 Language of Page from the WCAG 2.2. AA Requirements.
Updated ARIA Labels for links on course overview page
On the main page of a course (the course overview page) there are some links which only use an icon and not an accessible name. These two links have been updated to have an accessible name explaining where the links point to and how they should be used. This now allows screen readers to let the user now where the link is for.
This update is based on the criteria 2.4.4 Link Purpose (In Context) from the WCAG 2.2 AA Requirements.
Clear Focus Rings for Keyboard use
This update is based on the following criteria's from the WCAG 2.2 AA Requirements:
The design and understanding has been largely based upon this article.
Improved Form Validation (Messages)
To make sure form validation (messages) are easier to understand by a screen reader we made the following improvements across the application:
make sure to add aria-required if a field is required;
make sure to add aria-invalid if a field is invalid;
make sure the validation messages are programmatically linked to the input fields (not only in order);
make sure the validation messages are programmatically marked as important for screen readers to read.
These updates ensure that form validation and messages related to invalid input from the user are easier to read and understand for screen reader users.
These updates are based upon the following criteria from the WCAG 2.2. AA Requirements:
In addition, we used the following articles/blogs for inspiration on how to implement a good system:
Make Language Switcher Screen Reader Accessible
The language switcher in the navigation bar was not accessible for screen readers (i.e. it did not have a descriptive name). We updated this and make sure it is clear where the button is for.
Sortable Tables
In our application we regularly use sortable tables (mainly for teachers, but also for students). Upon testing these out we noticed that the state of sorting was not always easy to understand, both from a screen reader perspective as from a visual viewer perspective.
Therefore we updated the way we present (sortable) tables and ensured they are easier to operate with a keyboard and screen reader. We did this by applying the following updates:
make sure sortable column headers are buttons to which can be focussed on with clear (aria) labels such that a user understands they sort the table on that column value;
use icons to indicate which columns can be used to sort the data on and indicate also with a clearly distinctive icon which current column is sorted on (these icons are hidden for screen readers since we use aria attributes to indicate this for screen readers);
add captions to each table which are also programmatically linked to ensure that both screen reader users and non-screen reader users understand what the table is showing;
remove the underline for column headers since they are confusing since they look like links.
This update is mainly based upon our own insights based upon a collection of criteria and reading the following two articles which were a great inspiration to improve this:
Underline links by default and do not underline other things
We did not have a consistent styling for links and used the underline styling for both links and emphasis. To ensure that links are easy to recognise we did:
remove the underline style as base style for non-link elements (e.g. table header columns);
added a global link style in the application making sure links by default have an underline.
H1, H2 and H3 headers
To make it easier for screen readers to understand the structure of the page, we have updated our default headers to use H1 for our main page header and H2 for our page sub-headers. In addition, we are going through each page and check whether we want to add a H3 headers to more clearly indicate the different sections/parts in the page.
These updates are based upon the following criteria from the WCAG 2.2. AA Requirements:
Make Student Table Helper Accessible
In our testing we discovered the the way the table helper option for students during practice and tests was not very accessible for screen reader users. This was mainly due to the unclear focus management, unusable tabs in a tablist and the missing table captions.
We updated this feature such that is uses the accessible options we have to open a popup (with proper compliant and predictable focus management) and updated the tablist to be keyboard controllable (with the arrow keys as it should be to be compliant).
Finally, we also updated the tables itself to be more readable, for example by adding a caption to each table and ensuring the column (and row) names are easy to understand.
This update is based on the criteria 2.4.3 Focus Order from the WCAG 2.2 AA Requirements.