Accessibility Statement

beetroot & THERAPYAUDIT Limited

Summary

This policy defines the steps the company shall undertake in order to fulfil its obligations under:

• The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 https://www.legislation.gov.uk/uksi /2018/952/made
• Equality Act 2010

One of the key aims and tools that compliance with this policy is being met will be based on the: Web Content Accessibility Guidelines (WCAG 2.1), specifically that all services should meet at least AA level.

As per the Accessibility Regulations 2018, the company has an obligation to make a website or mobile application accessible by making it perceivable, operable, understandable and robust; provide an accessibility statement for each applicable application.

Scope

All Web Accessible Applications developed/owned by THERAPYAUDIT Limited, that are used by a public sector body including Web or Mobile Applications.

Principles

The Product Manager is responsible for ensuring that policy is adhered to.

The Lead Developer is responsible for ensuring the development team are following the practices laid out as part of this policy.

The Lead Tester is responsible for identifying defects in our software that would result in a degradation of any accessibility that we have already achieved.

The Support Manager is responsible for ensuring feedback concerning accessibility is correctly logged for the development team to action.

The Support Manager is responsible for ensure that all reasonable steps are taken in order to ensure that our support pathways are accessible.

Definitions

Web Accessible Applications refers to: applications (or mobile apps) provided by THERAPYAUDIT on behalf of their public body customers, e.g. the beetroot public health (e.g. beetrootCCARD, beetrootSTART) suite of products.

Accessibility Statement refers to: a statement outlining what the user can expect when interacting with the application from an accessibility context and the limitations of accessibility.

The policy

All Applications (as defined above) must:

1. meet level AA of the Web Content Accessibility Guidelines (WCAG 2.1) as a minimum
2. work on the most commonly used assistive technologies – including screen magnifiers, screen readers and speech recognition tools
3. have an accessibility statement that explains how accessible the application is and what features may not currently be accessible.

Staff Training and Development

1. Staff are given Accessibility training as part of their introduction (including equality and diversity).
2. The aim is that initially, staff with a responsibility or development requirement linked to accessibility will be prioritised for training to ensure basic adoption as soon as possible. Eventually, as part of staff training, all staff shall be offered Accessibility Training or equivalent awareness training depending on their business need.
3. Proposed Courses are: Digital Accessibility Foundations – Provided by Web Accessibility Initiative (WAI), or ii.Introduction to Web Accessibility.

Software Development Lifecycle

1. Design features are carefully chosen with accessibility in mind, large blocks of small text are avoided, buttons are made obvious with large text, and a colour change when hovering over them with an appropriate level of contrast.
2. 1.  Development
      1. The development team shall make use of accessibility features where available/appropriate.
      2. Where the development team identify a possible discrepancy between design and implementation this shall raised in accordance with our escalation processes.
      3. Special care is taken to ensure that technical fixes do not impact on accessibility. c. Testing
      4. Using a combination of internal tools (e.g. TAAutomatedTester) and open source tools (e.g. Wave, Selenium.Axe for . NET) accessibility for each page shall be reviewed. ii.Accessibility test failures shall be logged along with an appropriate severity rating as part of our issues tracking process.
      5. During the Beta or Pilot phase, stakeholders shall be able to raise accessibility issues directly to the assigned Project Manager.
      6. The assigned Project Manager shall liaise with the appropriate team/stakeholders and shall log the issue with an appropriate severity rating as part of our issues tracking process.
      7. Full accessibility audits including using tools for screen reading are conducted as the product enters the beta phase.
      8. Due to availability and cost, we currently use NVDA Screen Reader https://webaim.org/projects/screenreadersurvey9/ 
      9. Customers shall be able to raise support tickets (see below) for issues relating to digital accessibility. These will then be assessed and a response provided with regard to the expected timelines to resolution and if a suitable workaround can be used.
      10. Consideration shall be taken with regard to the:
          1. complexity
          2. scope
          3. technical ability to resolve the issue (e.g. third party controls) iii. Where contracts require it, the customer shall be informed of any accessibility issues, identified by their users by way of the Principle Point of Contact.

Support Considerations

1. Customers shall be able to contact us via:
   1. 1. phone
      2. email
      3. online service (e.g. Teams, Zoom or Skype)
2. Whilst it is standard practice for all contact to go via the support desk (to ensure that we are managing our SLAs correctly and so that an individual’s availability does not impact support delivery). It is possible for a customer to opt to have their support managed by a named individual.