Pubble SaaS Ireland Ltd. “Pubble” is the company behind two brands: Chatify (customer support) and React Live (Live events). Both brands are pretty new – the website for React Live is still being built – and represent a concerted effort on our part to improve the messaging around both product sets. That said, when we worked on WCAG Compliance we felt it was important that we achieved compliance for both brands in tandem. Why? We have lots of customers that use both and we wanted to avoid a situation where one app was compliant and the other wasn’t.
WCAG Compliance is something that has been a priority for us for a while now. As a company, there’s no question that we wanted to make sure that our products do not discriminate against those with an impairment. Our customers also played their part, in gently nudging us towards compliance.
So we are delighted to announce that Chatify is now WCAG AA compliant.
And ReactLive is also WCAG AA Compliant.
Here’s how we got there:
Prep
Finding accessibility documentation over the internet is not hard, but selecting which one to follow and going through it can be overwhelming. WCAG does a great job of explaining the principles surrounding accessibility but what you do after it is your job as developer/ designer / company.
We followed the Yale University “Usability & Web Accessibility” WCAG 2 A and AA Checklist in making sure we subscribe to the accessibility principles and we also used browser extensions to check for any accessibility issues we might have.
Code Changes
Tools we used: WAVE powered by webAim, axe – Web Accessibility Testing, Web Accessibility Extension for VS Code. Wave is a powerful tool that reads generated code (DOM) and signals any accessibility issues. This is not enough though but it was a great place to start.
The Q&A (Product & Live) and Live Chat (Messenger) web apps were not designed in the beginning with accessibility in mind. We have now addressed that.
We checked all the input type elements and switched to using standard tags that are fit for purpose. So we use only <textarea> and <input> tags. Each field type has a <label> attached to it. Where needed, we used ARIA to change state and availability of the text input fields. In some cases we had to change structure of DOM to achieve this. In others, we ended up using ARIA to prevent screen readers from accessing what is not visible on screen. We set focus areas and defined order of tabs for keyboard navigation.
Behaviour/User Experience Changes
Tools we used: ChromeVox Extension, in browser keyboard navigation testing.
Tab, Tab, Tab – we made our web apps easily browsed by keyboard, by setting regions and making sure we had the correct DOM tag order for the expected flow. Navigating questions, conversations, navigating to separate tabs during an event, or even allowing screen reader to :read the number or persons or the moderators names from a list.
We checked flow and made sure that submit is triggered when the visitor expects and made sure that main part of the app is accessible just by using keyboard and by listening to the VOx Extension voice.
UI changes
Tools we used: Wave Evaluation tool, Contrast checker from WebAIM.
We changed the contrast so we can met the 4:5:1 recommended ratio, we increased font size and buttons, and avoided any font-weight below “normal”.
Below you can download our completed Yale WCAG 2 Checklist as of 06-03-2020:
We are constantly updating the code and with each release more elements from the list will be marked as “supported”. Given the nature of our software (widgets) some items on that list are marked with “N/A” as they do not apply.
Recent Comments