Accessibility in Sitecore Forms MVC
Reading time: 6 min
You may have been waiting a long time for this blog post. And for good reason: accessibility is a very important and topical issue for all of us – including developers. In some countries (especially Germany), accessibility of public facilities is required by law. But there is no reason why digital spaces should not follow the same ethos. It should be our job as developers to make the internet more accessible and barrier-free for everyone. In this way, we enable people with disabilities to participate more actively in society. As someone who has worked with disabled people in sport for 30 years, this topic is very close to my heart.
Sometimes it seems as if the whole world has disappeared into the internet, and to a certain extent that is true. Social contacts, entertainment, finance, education, work and so much more: creating an Internet that is accessible to all is not just about equal access to information. It’s also about equal opportunities. An accessible web gives people with disabilities the opportunity to participate more actively in society. Tim Berners-Lee, W3C Director and inventor of the World Wide Web, summed it up very well when he said: “The strength of the web lies in its universality. Access for everyone, regardless of disability, is a key aspect.”
However, it would be a mistake to see accessibility as charity. Everyone benefits from accessibility. People with or without disabilities, senior citizens, children, parents and people who are only temporarily restricted in their mobility. An elevator helps parents with baby carriages, the elderly and people with walking disabilities alike. The commitment to equal access goes beyond mere solidarity, it creates benefits for the community and society as a whole.
In this article, we take a look at some tips and tools for Sitecore Forms that improve accessibility. It doesn’t matter what language you write your code in or what technology you use, in the end you just need to take care of your HTML output and tag your elements with Aria attributes to have screen reader support or e.g. connect inputs and labels, use live regions, etc.
Tools – Software
Let’s start with a brief overview of some tools. There are several tools to check the behavior of a screen reader and to determine whether your website is accessible or not.
Non-visual desktop assistant
The most important tool I would like to introduce to you is the Non-Visual Desktop Assistant (NVDA). In my opinion, it is one of the best screen readers and the software most used by people with visual impairments. Although there are many browser extensions for screen readers, NVDA works on the entire Windows system. It is 100% free, open source, has an integrated Braille viewer and a voice viewer to see what the screen reader would read out.
Developer tools (Chrome)
Most modern browsers already have an accessibility tab in their developer tools that you can use to check whether your elements are accessible.
Contrast tester
You may have noticed that the developer tools already have a contrast check. This is helpful to meet the needs of people who are red-green colorblind. For them, red and green are perceived as shades of gray, but that doesn’t mean that the website has to be black and white. However, you should be careful with the contrasts.
https://webaim.org/resources/contrastchecker/
https://github.com/ThePacielloGroup/CCAe
HTML validator
We always want to generate valid HTML output, and we use the HTML validator for this.
What happens next?
That was quite a long introduction, but it was necessary to sensitize you to the topic. Now we will cover all the backend changes to be upgradeable. These changes will not be affected by future Sitecore updates and do not need to be overwritten. Let’s take a look at it.
Backend customizations
A lot may have changed after the symposium. However, this does not mean that the changes cannot be introduced in the core DB! As I have already mentioned, we live in a SaaS world these days. All these changes could easily be rolled out in XM Cloud, but you still need to take care of the front end. My next tasks will be to do this on Next.js or another modern framework.
The main task was to revise the entire Sitecore Forms backend. That means I hide all the standard sitecore
Expander, create my own new expanders, copy all the fields I want to have accessible, and finally add all these fields to my custom expanders.
I have put all fields in the master DB in a separate folder and copied all standard fields so that they are upgradeable. Sitecore’s default expanders have been hidden to show the customer only the fields that are ready for accessibility (not part of the package).
A lot of changes have been made to the views. Here is a comparison between the Sitecore default view and mine:
Standard view:
Customized view:
As you may have noticed, I have made a lot of changes to the views. However, this can also be easily adapted to Next.JS. It’s just a matter of retrieving the fields from the backend and rendering them. The interesting thing is that what I changed in Core DB, Sitecore Rocks is still not dead!
First, I added new expanders to the Sitecore Forms backend. They are all marked as A11Y (abbreviation for accessibility):
These expanders contain several fields that are prepared for accessibility:
As you can see, all fields are marked with (A11Y) to recognize the difference between the standard sitecore fields and the revised fields. At some point you may want to hide the standard extensions, but that is up to you. So, that was pretty easy, but now let’s take a closer look at the fields themselves. This is where the magic happens.
Validation
Many developers wanted custom validation messages in MVC instead of the default Sitecore validation messages. The solution was to add an additional field to the “Validation Expander”. Check that it is not empty, otherwise use the standard sitecore validation as a fallback. And that’s it! From now on, these messages will be user-friendly.
Imagine that the standard validation message for a telephone number is “Telephone number is required”. From now on you can have a validation message like “Please enter a phone number, the format should be +49 1111 1111111”. That’s much friendlier, isn’t it? You can set these messages for each language, otherwise the standard sitecore message is displayed.
Autocomplete
This is one of the most important functions that has been added. You may all know that your browser knows what you have entered when you fill in different forms several times. But how often does it happen that you have entered a phone number or a cell phone number, and in another form your cell phone number is used as the phone number, and so on? You can now enter the corresponding values directly in the fields. Combined values are also possible, e.g. “Private phone”, “Work phone” or “Mobile phone”. This is a great help for people with visual impairments. Or imagine that people with only one arm can fill out the form with just ONE click!
All these values are added to the fields as aria attributes and recognized by the screen readers.
Security
A final addition to the fields is a new security field called“Honeypot“. This is a spam trap. You all know how to use captchas to prevent forms from being submitted by a bot, which can unfortunately lead to websites being shut down.
There are various captchas, such as audio captchas or re-captcha, where you have to find traffic lights in 3×3 tiles. But remember that we are talking about people with visual impairments or people who cannot hear. All these captchas will not work for them.
Honeypot is a simple solution for preventing spam entries in forms. It is actually just a hidden field. And this is how it works: Bots fill in every field of a form, even the hidden ones. What I’ve added is just a JavaScript to prevent that on the client side, and also a custom submit action to prevent that on the server side. If you want to use the honeypot field, remember that you must also use the submit action in your form. This will prevent all spam form submissions in the future!
Let’s make the Internet a little more accessible together
If you are looking for more information, you can find all these topics in the official Web Content Accessibility Guidelines (WCAG). This is the universal documentation for accessibility on the Internet. In Germany, all public facilities must be barrier-free; this is covered by the “Barrier-free Information Technology Ordinance” (BITV) and its test steps, which are required before commissioning. Good documentation for developers can also be found in the Mozilla Developer documentation for Accessibility.
At the moment I don’t have the opportunity to test the features of the new XM-Cloud Forms product, but I am in contact with them to make XM-Cloud Forms available as well.
The package is available at https://github.com/monkey-dsc/A11Y.Feature.Forms/. It is compatible from 9.2.0-10.3.1, but read the installation instructions carefully as there may be conflicts with the operators and action items in your current environment, but this is well documented.
