Accessibility

As part of the Rhino Products Group’s commitment to complying with the 2010 Equality Act and supporting accessibility throughout all areas of our business, we have reviewed various UK and EU regulations relating to website accessibility during the development process of our corporate websites. While much of this legislation may not strictly apply to our business, and is required only for public service/sector organisations, we have made every effort to make our websites as accessible as possible for individuals who may otherwise have difficulty in this area.

We have based this approach to accessibility on official government advice.

2010 Equality Act

The key piece of legislation we have adhered to is the 2010 equality act which requires service providers to make “reasonable” adjustments to ensure that a disabled person is not at a substantial disadvantage when using a website in comparison to persons who are not disabled. This act points to advice set out by organisations such as the Worldwide Web Consortium (W3C) which publish guidance in this field. We have used W3C resources to guide our web development team to produce a website designed and structured to be fully accessible to all users.

Further to this, the 2010 equality act states that we need to be able to make reasonable adjustments or be able to provide the information present on the website in alternative formats if required and requested where reasonable. The Rhino Products group prides ourselves on exceptional levels of customer service and have a customer service team available to call 5 days a week who could provide any of the information found on the website over the phone. We also have an inhouse marketing team who would be able restructure information into another required format if reasonably requested to do so.

Accessibility Regulations 2018

In order to fully comply with the 2010 Equality Act, we have also designed the website to adhere to the more recent regulations around website accessibility called: Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, which build upon the 2010 Equality Act. Organisations this applies to need adhere to WCAG criteria. We have summarised the points from this criteria that we comply with below.

Perceivable

• provide text alternatives (‘alt text’) for non-text content
• provide transcripts for audio and video
  provide captions for video
• make sure content is structured logically and can be navigated and read by a screen reader – this also helps if stylesheets are disabled
  • The website still works without CSS, so screen readers can still access the text
• use the proper markup for every feature (for example, forms and data tables), so the relationships between content are defined properly
• not use colour as the only way to explain or distinguish something
  use text colours that show up clearly against the background colour
• make sure every feature can be used when text size is increased by 200% and that content reflows to a single column when it’s increased by 400%
  • At 400% the website will perform like a mobile device
• not use images of text
• make sure your service is responsive – for example to the user’s device, page orientation and font size they like to use
• make sure your service works well with assistive technologies – for example, important messages are marked up in a way that the screen readers knows they’re important
  • Achieved through the use of ALT tags etc.

Operable

• make sure everything works for keyboard-only users
  • Website compatible when used with mouse and keyboard shortcuts that can be modified on the users machine
• let people play, pause and stop any moving content
• not use blinking or flashing content – or let the user disable animations
• provide a ‘skip to content’ link
• use descriptive titles for pages and frames
• make sure users can move through content in a way that makes sense
• use descriptive links so users know where a link will take them, or what downloadable linked content is
• use meaningful headings and labels, making sure that any accessible labels match or closely resemble the label you’re using in the interface
• make it easy for keyboard users to see the item their keyboard or assistive technology is currently focused on – this is known as ‘active focus’
• only use things like mouse events or dynamic interactions (like swiping or pinching) when they’re strictly necessary – or let the user disable them and interact with the interface in a different way
  • Website compatible when used with mouse and keyboard shortcuts that can be modified on the users machine
• make it easy for users to disable and change shortcut keys
  • Website compatible when used with mouse and keyboard shortcuts that can be modified on the users machine

Understandable

• use plain English
• keep sentences short
• not use words and phrases that people won’t recognise – or provide an explanation if you can’t avoid it
• explain all abbreviations and acronyms, unless they are well known and in common use – for example UK, EU, VAT
• make it clear what language the content is written in, and indicate if this changes
• make sure features look consistent and behave in predictable ways
• make sure all form fields have visible and meaningful labels – and that they’re marked up properly
• make it easy for people to identify and correct errors in forms – you can find best practice for form design in the GOV.UK Design System

Robust

• use valid HTML so user agents, including assistive technologies, can accurately interpret and parse content
  • There are no HTML issues that should impact a screen reader’s ability to read the website
• make sure your code lets assistive technologies know what every user interface component is for, what state it’s currently in and if it changes
• make sure important status messages or modal dialogs are marked up in a way that informs user of their presence and purpose, and lets them interact with them using their assistive technology
  • No modals in use on this website
• lets the user return to what they were doing after they’ve interacted with the status message or modal input
  • No modals in use on this website