This accessibility statement applies to the staff member experience of the Access web application, which is developed by Symplicity and configured and populated with content by our clients and their constituents. We are continually improving the user experience by applying relevant accessibility standards. We are committed to:
We want as many people as possible to be able to use this web application. For example, that means you should be able to:
We’ve also made the web application text as simple as possible to understand.
AbilityNet has advice on making your device easier to use if you have a disability.
We know some parts of this web application are not fully accessible:
If you need information on this web application in a different format like accessible PDF, large print, easy read, audio recording or braille:
We’re always looking to improve the accessibility of Access. If you find any problems not listed on this page or think we’re not meeting accessibility requirements, please contact us. Our product support team will review your message and follow up via email.
Enforcement varies by country and locality. The list below is partial.
In the United States, the Office of Civil Rights is responsible for enforcing Section 508 of the Americans with Disabilities Act.
In the UK, the Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the ‘accessibility regulations’).
In Northern Ireland, the Equalities Commission for Northern Ireland (ECNI) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the ‘accessibility regulations’).
Find out how to contact us on our web site.
Symplicity is committed to making its web application accessible, in accordance with:
the US Section 508 of the American with Disabilities Act
the UK Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018
This web application is partially compliant with the Web Content Accessibility Guidelines version 2.1 AA standard, due to the non-compliances listed below.
The content listed below is non-accessible for the following reasons.
Some pages have heading tags that skip a level. This fails Criterion 1.3.1 Info and Relationships. We plan to review and update these pages.
The collapsible sidebar components can only be collapsed by clicking the header. We plan to update to use both the click and enter key events. This fails Criterion 2.1.1: Keyboard. We plan to include pressing enter to fire the action.
The extra list filters that can be exposed appear above the button so a keyboard user has to go backwards to access them. This fails Criterion 2.4.3 Focus Order. We plan to move the button above the fields.
Some form inputs cause a page refresh, without warning, in order to minimize the number of required fields. This fails Criterion 3.2.5: Change on Request. We plan to warn the user before this happens.
Some dropdowns, popups, and collapsible areas, don’t behave like a native component by announcing that it’s open or closed; and values can only be accessed with tab keys. This fails Criterion 4.1.2 Name, Role, Value. We plan to add the proper aria attributes, roles, and scripting, so that it behaves like a native component.
We have prioritized these accessibility improvements based on analytics and data. We try to make accessibility improvements a high priority. Usually, we are able to make accessibility improvements very quickly. Some improvements are complex and require more time for planning, development and testing.
Calendars
The calendar does not provide markup that provides information and establishes relationships in a way that can be understood by a screen reader user. The calendar does not provide necessary functionality, and most of the information displayed on the calendar is accessible via other modules in an accessible format. This fails WCAG 2.1 success criteria.
Converted and Generated PDFs
PDF documents are typically used for student resumes/CVs, and other application materials. Users may upload a non-PDF document, which is then converted to PDF. These converted PDFs may not be fully accessible. When PDFs are compiled into a publication (or “packet”), these publications may not be fully accessible. PDF accessibility can only be achieved by manual process on a per-document basis.
We’ve assessed the cost of fixing the issues above. We believe that doing so now would be a disproportionate burden / undue burden within the meaning of the accessibility regulations. We will re-assess this at least once per calendar year.
We have not identified any content that is not within the scope of the accessibility regulations.
This web application was last tested on May 6, 2020. The test was carried out by a Symplicity accessibility specialist. In this test, we used critical path analysis, usage data, and our knowledge of the application architecture to determine a sample of pages to test.
Accessibility is a consideration at every stage of our process. Accessibility training is required for every designer and developer who works on the user interface. Automated and manual evaluations are performed throughout the design, development, and quality assurance process. Remediation of accessibility issues are given a high priority, and is generally performed in a timely manner.
Our accessibility roadmap is available upon to our current and prospective clients upon request.
This statement was prepared on September 23, 2020. It was last updated September 23, 2020.
Provides institutions with the ability to connect holistically with students to enhance their experience and streamline campus operations and collaborations.
© Copyright All Rights Reserved 2024 Symplicity