Building accessible applications with Student Details Form (SDF)
Text: Howard | Content: Zheng Yuan
The Student Details Form (SDF) is a digital portal built by ESTL that streamlines student data collection for schools. (Click here to learn more!) Soon, we are releasing phase 2 of SDF, where it evolves from serving parents of incoming Primary 1 students to parents of all students. As our user base is expected to greatly increase in size, a question that came to our mind was ‘is our app accessible for all our users?’
Web accessibility is about creating technologies that can be used by everyone, including people with disabilities. There are various types of disabilities that may impede someone from using a product. In the case of web applications, vision disabilities — such as blindness, low vision, and colour blindness — are a huge hurdle, which is where we focused our efforts on.
When an unsighted user surfs a browser, he/she typically uses a screen reader that reads out the content of the page. In that case, it’s a problem solved, right?
Unfortunately, that’s not the case. As we quickly learned, many important considerations must be made to ensure that the screen reader can interpret the contents of a page. Here are some of our takeaways.
About screen readers
One consideration is the type of screen readers used. There are many different screen readers in the market. Based on a survey conducted in 2021, the top screen readers used are Job Access With Speech (JAWS) and NonVisual Desktop Access (NVDA), accounting for nearly 80% of usage.
If you are familiar with web development, then you are not new to browser compatibility problems. Screen readers have the same issue — different screen readers are implemented differently, which is a pain for engineers.
Assistive technologies, like screen readers, interpret and announce a HTML element by its ARIA attribute. However, not all types of ARIA attributes are supported by every screen reader. Take a look at the compatibility table below regarding a basic ARIA error message:
Due to the lack of universal compatibility, we could not use some ARIA attributes, even if they are available. In these cases, we used more general ARIA attributes that are supported by most screen readers. In the case of error messages, we found that the aria-describedby attribute is especially helpful.
The aria-describedby attribute
The aria-describedby attribute allows a HTML element to be the assistive text of another HTML element. In the example below, the “Move to trash” button can be described by the paragraph below. This connection is made by specifying the paragraph’s element id in the button’s aria-describedby attribute.
One way we use this in SDF is when a user tries to submit data that has errors. When this happens, the erroneous fields become highlighted in red, making them immediately apparent to the sighted user. However, for the unsighted users, the screen reader needs to announce that a field contains an error in addition to the normal content.
By adding the error element’s id to the Select element’s aria-describedby attribute, the screen reader would announce the error text when the error element is rendered.
No ARIA is better than bad ARIA
As developers, we may be tempted to simply include ARIA attributes in our components to instantly meet accessibility requirements for our apps. However, this is not always valid. If the attribute was implemented wrongly, this could further impede the unsighted user instead of providing them with a better experience.
For example, some teams may choose to use custom div tags in place of native HTML tags to render their components. They then add a bunch of ARIA attributes to the custom tag. As much as possible, this should be avoided as native HTML tags come with proper ARIA implementation out of the box.
You can refer to the ARIA Authoring Practices Guide to better understand the accessibility implementations of every element and ARIA attributes.
Automated tests are helpful only to an extent
There are various tools that help to automatically assess the accessibility of digital applications. They implement certain rules that alert you if one of the accessibility criteria is not met. Here are some of the ones available:
- Google Lighthouse
- Govtech Purple Hats
- Jest + Axe
- Storybook A11y Add-on
In our case, we use Jest as the testing tool, and Axe as a plugin that defines the accessibility rules for the rendered HTML.
While tools are helpful, they are not the end-all guarantee that an application is comprehensible by an unsighted user. For example, the Student Details Form has edit buttons plastered around the form that allows for editing. As long as each button has an “edit” label, the screen reader would announce “edit” and the automated tests would pass. However, the unsighted user would still be clueless about what he was editing. For clarity, the context should be added to the label as well. For example, “edit child’s contact details”
For us, there is at least one reliable test to ensure that a web content is comprehensible to the unsighted user — put on a pair of blindfolds and navigate through the content ourselves! If we can navigate the application relying purely on screen readers, then we have the assurance that our basic accessibility considerations have been met. Otherwise, it’s back to fixing.
In conclusion
When we design applications, it is important to consider the usage for people with disabilities, especially for public-facing applications. The sooner we consider this in our development roadmap, the better we can support the various concerns that could arise regarding accessibility. While this might be a huge development effort for a small group of people, it would really mean a lot for them.
We hope that some of our learnings can help you with your own efforts in supporting web accessibility!
