search icon

Accessibility statement for Sage Intacct

Updated 31 July 2024

Sage Intacct is a cloud accounting application for businesses, which provides core accounting capabilities supplemented by solutions to automate complex revenue and billing processes, financial and budgeting capabilities, integrations with third-party software products, reporting, and additional advanced modules for financial management.

This statement outlines our accessibility commitment for Sage Intacct and reflects our efforts to comply with the Web Content Accessibility Guidelines (WCAG) version 2.1, Level AA.

Our Dedication to Accessibility

We are dedicated to improving accessibility within Sage Intacct, ensuring it is more usable for people with disabilities. Our efforts are ongoing and aimed at continuously enhancing accessibility by integrating keyboard navigation, screen reader support, and more comprehensive use of ARIA tags and semantic HTML.

When using Sage Intacct, our goal is for all users to be able to: 

  • Use the web product on large screens without the need to scroll the page horizontally (separate mobile apps are available which will be covered by their own accessibility statements).
  • Navigate using consistent menus, or a visual process map.
  • Zoom in by 150%, or change the size and spacing of text, without the text running off screen.
  • Use the search feature to quickly access content.

AbilityNet also has advice on making your device easier to use if you have a disability.

Important notes:

  • Sage Intacct is currently updating the technology used to build this product. We’re bringing in improved accessibility support as we go, but not all features benefit from this technology yet.
  • Sage Intacct is a highly customizable, including by third party developers. Your implementation of Sage Intacct may differ from this statement.

Technical information about accessibility

We tested Sage Intacct with the Web Content Accessibility Guidelines version 2.1, AA standard. As part of our commitment to continual improvement, we plan to continue working to enhance our accessibility support even further.

Non-text Content

We would like all objects on a page that have meaning to have a text alternative.

WCAG Reference 1.1.1

Info and Relationships

We would like to make sure that information and relationships implied by visual formatting are clear to people using assistive technologies.

WCAG Reference 1.3.1

Use of Colour

We would like to make sure that colour is not used as the only visual means of conveying information.

WCAG Reference 1.4.1

Contrast (Minimum)

We would like the visual presentation of text to have good contrast against background colours to support people with visual impairments.

WCAG Reference 1.4.3

Non-text Contrast

We would like the visual presentation of everything that’s interactive to have good contrast against background colours to support people with visual impairments.

WCAG Reference 1.4.11

Keyboard

We would like everything that’s interactive to be accessible using the keyboard alone.

WCAG Reference 2.1.1

Bypass Blocks

We would like to provide features in code to allow users to bypass repeated blocks of content, for example, navigation that appears on every page, as this may help some users.

WCAG Reference 2.4.1

Page Titled

We would like each page to have a title in code that identifies its contents.

WCAG Reference 2.4.2

Focus Order

When using the tab button to move around, we would like the sequence of movement to be logical.

WCAG Reference 2.4.3

Headings and Labels

We would like all pages to provide clearer and more descriptive titles, and for all pages to have a ‘Heading 1’ in code.

WCAG Reference 2.4.6

Focus Visible

We would like to help people know which item has keyboard focus.

WCAG Reference 2.4.7

Label in Name

We would like the text we use for the labels of fields to be the same as the text we use for the field name in code to support speech input or text-to-speech users.

WCAG Reference 2.5.3

Language of Page

We would like to set the language of each page in code so content is always presented correctly.

WCAG Reference 3.1.1

Error Suggestion

We would like people to receive appropriate suggestions for the correction of an error if possible.

WCAG Reference 3.3.3

Parsing

We would like IDs in code to be unique, so the product works well for all users, but today some IDs are not unique. We’ve logged these cases to fix.

WCAG Reference 4.1.1

Name, Role, Value

We would like each field on the page to be associated with a label in code, however in some situations this isn’t the case (for example, checkboxes indicating table row selection, or fields in tables). To fix this, we’re working on updating how cases like this are coded.

We would also like all icons to have text descriptions in code so it’s clear to all users what they do. We found some that don’t have descriptions, and we’ve logged them to fix.

WCAG Reference 4.1.2

Status Messages

If a message appears, we would like it to be clear to all users.

WCAG Reference 4.1.3

Disproportionate burden

Reflow

Without the need to scroll the page horizontally, it is possible to use the web product on large screens (separate mobile apps are available which will be covered by their own accessibility statements).

However, if you use the product on screens below 1930 pixels wide, you’ll need to scroll horizontally to see some content.

All pages of the product would need to be fixed, including many pages with large tables of data. This would be costly and it’s often difficult to offer responsive variants of large tables without losing meaning. Some WCAG guidance suggests that ‘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.

WCAG Reference 1.4.10

How we tested this product

How We Test:

  • Regular Testing Cycles: We conduct accessibility testing on a quarterly basis, which allows us to actively monitor and address any new or outstanding issues. This regular cadence ensures that accessibility remains a priority throughout our development cycles.
  • Automated and Manual Testing: Our approach combines automated testing tools with manual evaluations. This dual approach helps ensure comprehensive coverage of both technical compliance and user experience optimizations.
  • Diverse Testing Environments: We test our platform using a variety of tools and environments to simulate different user experiences. This includes testing with popular screen readers, high contrast modes, and keyboard-only navigation across different operating systems such as Windows and MacOS.
  • Continuous Education and Training: Our development teams receive ongoing training in accessibility standards and inclusive design practices. This education ensures that accessibility considerations are integrated into the development of new features from the start.

Testing was conducted using:

  • Chrome version 80.0.3987.122 on Mac OS, and VoiceOver included with Mac OS 10.14.5 (Mojave).
  • Chrome version 80.0.3987.87 on Windows 10 version 1803.

Feedback and contact information

We know some parts of this product are not fully accessible.

If you need support, find problems not listed on this page, or if you believe we are not meeting accessibility requirements, please contact us.

We’ll consider any requests and get back to you as soon as possible.

Give Feedback