We want as many people as possible to be able to use Sage Business Cloud Accounting. For example, that means you should be able to:
We have made the text in the product as simple as possible to understand.
AbilityNet also has advice on making your device easier to use if you have a disability.
Important note: Sage Business Cloud Accounting is currently updating the technology that it is built on. We are bringing in improved accessibility support as we go, but not all features benefit from this technology yet.
There are several other improvements we could make to our code to help the product work as well as it could for everyone
If you need support, find any problems not listed on this page, or if you think we’re not meeting accessibility requirements, please contact us.
We will consider any requests and get back to you as soon as possible.
The content listed below is non-accessible for the following reasons.
We would like all objects on a page that have meaning, to have a text alternative. However, sometimes text alternatives aren’t available, they are not easy to understand, or they do not match what is presented visually. We are working to fix this by replacing older code and resolving identified bugs.
We would like the type of each field on the page to be clearly visible in the code so that the fields are presented in the most useful way to users. Right now, this is not always the case. To fix this, we’re working on updating the code for all fields.
Sometimes we intentionally disable autocomplete where it would not be helpful.
We would like the visual presentation of the text to have good contrast against background colours to assist people with visual impairments. However, in some places, this is not the case. To fix this, we’re working on improved visual styles and phasing out the use of placeholder text.
We would like the visual presentation of everything interactive to have good contrast against background colours to assist people with visual impairments. However, in some places, this is not the case. To fix this, we are working on improved visual styles.
We would like everything interactive to be accessible using the keyboard alone. However, our site navigation, tables, and some buttons are not yet keyboard accessible. To fix this, we are working on new navigation, tables, and buttons.
We would like to avoid situations where you might get stuck if using the product with the keyboard alone. Right now, tabbing to the end of some message boxes means keyboard focus is lost and you need to press the Esc key to exit. To fix this, we are rebuilding our message boxes.
We would like to provide features in the code to allow users to bypass repeated blocks of content, for example, navigation that appears on every page, as this may help some users. These features are not present in the product today, but we will add them.
When using the tab button to move around, we would like the sequence of movement to be logical. However, our testing revealed some situations in which the order is not as we would expect. We are working to fix this.
We would like to offer users more than one way to navigate around the product. However, today we only provide navigation menus. To fix this, we are investigating adding features like a search.
We would like the text we use for the labels of fields to be the same as the text we use for the field’s name in the code to support speech input or text-to-speech users. While the code does contain the label text, it is combined with other content that makes it difficult to understand. To fix this, we will use different naming conventions.
We would like to set the language of each page in the code so that the content is always presented correctly. This code is not present in the product today, but we plan to add it.
We would like all errors to be apparent, especially if using a screen reader. However, errors that appear after certain actions are not always apparent. To fix this, we are working on new error messages and reviewing the mechanism we use to present errors.
If possible, we would like people to receive appropriate suggestions for the correction of an error. However, some error messages are worded broadly, and many do not include specific suggestions for correction. We will review our error message content.
We would like IDs in the code to be unique, so the product works well for all users, but some IDs are not unique for now. We have logged these cases for fixing.
We would like each field on the page to be associated with a label in the code however, this is not the case in some situations (for example, checkboxes indicating table row selection or fields in tables). To fix this, we are working on updating how cases like this are coded.
We would also like all icons to have text descriptions in the code so that it is clear to all users what they do. We found some that do not have descriptions and we have logged them for fixing.
If a message appears, we would like it to be clear to all users. Currently, messages are not coded in a way that users of some assistive technologies would notice. To fix this, we are developing how our messages are coded.
It is possible to use the web product on tablets with landscape (horizontal) orientation and larger screens than this, without the need to scroll the page horizontally. (Separate mobile apps are available that will be covered by their own accessibility statements).
However, if you use the product on tablets with portrait (vertical) orientation or on smaller screens such as smartphones, you will need to scroll horizontally to see all the content.
All pages of the product would need to be fixed, including many pages with large tables of data. This would be costly as it is often difficult to offer responsive variants of large tables without losing meaning, and some WCAG guidance suggests that a 'two-dimensional layout for usage or meaning’ may be acceptable.
We believe that offering support for smaller screens would be a disproportionate burden within the meaning of the accessibility regulations. We will make regular further assessments.