Accessibility Frequently Asked Questions
On this page we have listed answers to some frequently asked questions regarding the accessibility of our products, and the reasons behind some of our design choices.
Which screen readers do you use to test your products?
We aim to test our products using the most popular screen readers for each major platform.
- Windows: We use the NVDA and JAWS screen readers. Currently NVDA is the most popular free screen reader for Windows, and JAWS is amongst the most popular commercial offerings. While the built-in Narrator screen reader has improved considerably in recent years, many regular users prefer a dedicated screen reader product. That being said, the fact that Narrator is installed by default makes it a useful tool for verifying the accessibility of a particular page.
- Mac: We use the VoiceOver screen reader that is included with the operating system.
- Linux: We use the Orca screen reader that is shipped with many popular Linux desktop environments.
- Android and iOS: We use the built-in screen readers that ship with the operating system.
Accessibility of our Self-Service portals
This section relates specifically to accessibility of our self-service portals.
Why do you not use the <fieldset> element to group radio buttons?
The W3C Web Accessibility Initiative (WAI) outlines two methods for grouping controls. The first is to use the <fieldset> element with an associated <legend> element to describe the group. The second method uses ARIA to add a role attribute to the div element that contains the radio buttons, and this is the approach we take. The benefit of the ARIA approach is that it allows us to have greater control over the styling without impacting on accessibility. Screen readers will function equally well with either approach. You can read more about guidelines for grouping controls on the official WAI documentation.
Why do dropdown lists report a warning about use of Javascript jump menus?
We attach an onchange event handler to our dropdown list controls so that form designers can implement logic based on selected values, and some accessibility audit tools such as WAVE think that this event handler is an indication that a jump menu is being used. We don't use any kind of jump menus or anything that would result in the focus being moved unexpectedly.
How long do users have to complete an online form before their session times out?
There is a minimum 60 minute timeout threshold across all our portals. This means that provided the user does not spend more than 60 minutes on an individual page of a form, their session will not time out.
We put a lot of effort into the design of each form to help users complete their transaction in a timely manor, for example by advising the user of any specific information or documents they may need at the very start of the process.
We are often asked why sessions can not just be set to never time out. The answer is that our forms are highly transactional in nature, and we need to balance the usability of our forms against the resources required to operate the service. For longer or more complex forms we provide users with the option to save their form at any time so they can come back to it later.
How to contact us regarding the accessibility of our products
If you would like to contact us regarding the accessibility of our products, we have a dedicated e-mail address that will ensure your enquiry is directed to the appropriate team. Please e-mail accessibility@pentagull.co.uk.
If you believe you have found an accessibility issue with our product, please include as much information as possible such as the version of the web browser, type of assisted technology being used, and steps to reproduce the issue if possible.
Although automated tools can be a great help in identifying accessibility issues, we do not consider an alert or error generated by an automated tool to be a problem unless it can be verified using a real world example. This is due to the fact that most tools are capable of generating false positive findings. Likewise, just because an automated tool finds no problems with a site does not make it necessarily accessible, as it is possible to meet all the documented standards but still make a site inaccessible.