Accessibility statement for the staff member experience of Symplicity Advocate

This accessibility statement applies to the staff member experience of the Advocate 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:

  • ensuring that this web application achieves “Level AA” conformance to the Web Content Accessibility Guidelines (WCAG) 2.1
  • striving for this web application to achieve “Level AAA” conformance to the Web Content Accessibility Guidelines (WCAG) 2.1.
  • including conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 when we procure 3rd-party systems or upgrades to existing systems.

We want as many people as possible to be able to use this web application. For example, that means you should be able to:

  • access all content easily
  • have descriptions of images are on the screen
  • interact confidently with forms and tables
  • not worry about automatic media and navigation
  • change colors, contrast levels and fonts
  • zoom in without the text spilling off the screen
  • navigate most of the web application using just a keyboard
  • listen to most of the web application using an up-to-date browser and screen reader (including the most recent versions of JAWS, NVDA and VoiceOver)

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.

How accessible this web application is

We know some parts of this web application are not fully accessible:

  • pages have headings which skip a level
  • some custom form components do not behave in the same fashion as a native browser component
  • Focus order is wrong for list filters that are exposed after being hidden
  • Some actions require a click and cannot be fired with a keyboard
  • the text will not reflow in a single column when you change the size of the browser window
  • you cannot modify the line height or spacing of text
  • PDF documents are not fully accessible to screen reader software
  • some of our forms are difficult to navigate using just a keyboard

What to do if you cannot access parts of this web application

If you need information on this web application in a different format like accessible PDF, large print, easy read, audio recording or braille:

  • Call or email the office or department in your university/organization. Contact information is usually found in the footer of the Advocate web application.

Reporting accessibility problems with this web application

We’re always looking to improve the accessibility of Advocate. 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 procedure

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’).

Contacting us by phone or visiting us in person

Find out how to contact us on our web site.

Technical information about this web application’s accessibility

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

Compliance status

This web application is partially compliant with the Web Content Accessibility Guidelines version 2.1 AA standard, due to the non-compliances listed below.

Non-accessible content

The content listed below is non-accessible for the following reasons.

Non compliance with the accessibility regulations

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 picklist manager has buttons that cannot be accessed via keyboard. This fails Criterion 2.1.1: Keyboard. We have a fix for this that will be released soon.

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.

Disproportionate burden

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.

Content that’s not within the scope of the accessibility regulations

We have not identified any content that is not within the scope of the accessibility regulations.

How we tested this web application

This web application was last tested on May 24, 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.

What we’re doing to improve accessibility

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.