Royal Botanic Gardens, Kew

Accessibility audit and testing

16 Incomplete applications

16 SME, 0 large

17 Completed applications

16 SME, 1 large

Published: Monday 3 February 2020
Deadline for asking questions: Monday 10 February 2020 at 11:59pm GMT
Closing date for applications: Monday 17 February 2020 at 11:59pm GMT

Overview

Summary of the work: Web accessibility audit of RBG Kew's digital products to ensure compliance with WCAG 2.1 AA requirements, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
Latest start date: Friday 28 February 2020
Expected contract length: 2 months
Location: South West England
Organisation the work is for: Royal Botanic Gardens, Kew
Budget range: Maximum £20,000.

About the work

Why the work is being done: The organisation wants to ensure that RBG Kew's public-facing digital products comply with WCAG 2.1 AA requirements. In order to do that, we expect to undertake a mixed audit of desk-based research and testing with real users against a range of Kew's websites to highlight areas of issue, with expected outcomes that can be corrected and re-tested to ensure compliance.

Work is required to commence by no later than 09/03/2020, only suppliers who can meet this start date should apply and will be considered.
Problem to be solved: Organisation wants to ensure that RBG Kew's public-facing digital products comply with WCAG 2.1 AA requirements. In order to do that, we expect to undertake a mixed audit of desk-based research and testing with real users against a range of Kew's websites to highlight areas of issue, with expected outcomes that can be corrected and re-tested to ensure compliance.
Who the users are and what they need to do: "Needs:
As a sight impaired user: to use a screen magnifier; sufficient contrast between foreground/background colour combinations; to use a screenreader to navigate a webpage; text alternatives to images, controls, or other structural elements
As a user with physical/motor disabilities: to navigate a webpage without the use of a mouse or trackpad; sufficient time to complete a webform
As a deaf user: to read captions on a video
As a user with speech disabilities: to communicate without voice interaction
As a user with cognitive, learning, or neurological disabilities: navigation mechanisms and page layouts that are easy to understand and use"
Early market engagement
Any work that’s already been done: "The last accessibility audit was completed in March 2019 and focussed on 13 pages across kew.org, shop.kew.org, adoptaseed.kew.org, careers.kew.org, powo.science.kew.org, and tickets.kew.org/WebStore/shop/ViewItems.aspx.
"
Existing team: You'll be working primarily with Kew's Digital Experience team, and primarily with the Head of Digital Experience, Senior Product Manager, Product Manager, Junior Product Manager, UI Designer, Senior Content Manager and Content Producers. Where relevant you'll also work with stakeholders in other teams across Kew.
Current phase: Not started

Work setup

Address where the work will take place: Royal Botanic Gardens, Kew, Richmond
Working arrangements: We expect the majority of work to be completed remotely away from RBG Kew's offices. We expect to have regular contact points during the duration of the contract, with at least three face-to-face meetings.
Security clearance

Additional information

Additional terms and conditions

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Essential skills and experience: Recent (within the last 12 months) experience of auditing digital products for users with a range of disabilities against WCAG 2.1 to meet AA requirements (20 points)

Experience of desk-based research to test digital products for accessibility issues for at least 2 clients (20 points)

Experience of engaging with users with a range of disabilities to test digital products for accessibility issues. (20 points)

Experience of delivering documentation to highlight areas of accessibility issues with expected outcomes. (20 points)

Experience of working alongside additional suppliers and in-house teams to deliver accessibility improvements for digital products. (10 points)

Experience of delivering value for money by working in partnership with public sector clients to scope and prioritise against business/user needs. (10 points)
Nice-to-have skills and experience

How suppliers will be evaluated

All suppliers will be asked to provide a written proposal.

How many suppliers to evaluate

Proposal criteria

Provide an example of how you have worked with a client to provide outcomes to apply amendments to a digital product to correct accessibility issues. (30 points)
Please provide an example of how you have worked with a client to re-assess reported outcomes to ensure website accessibility issues have been corrected satisfactorily. (15 points)
Please provide a proposed timeline for completing the work detailed. (15 points)
Please detail your understanding of the different and competing priorities we face as an organisation, particularly around web accessibility. (5 points)
Outline an end-to-end website accessibility audit project you delivered, including methodology, engaged users, documentation, delivery, and any challenges you faced and an outline of benefit realisation. (30 points)
Outline what you think makes a successful agency/client partnership, provide an example where you have achieved this (please include this client as one of your references). (5 points

Cultural fit criteria

Demonstrate understanding of the different audience needs faced by complex non-profit organisations (20 points)
Demonstrate an evidence-driven approach with an example of where you have used analytics or user research to influence outcomes (20 points)
Provide an example of where you have worked with in-house development and IT resources to deliver on a project (20 points)
Provide evidence of supporting an in-house digital team with stakeholder engagement to deliver solutions that meet both user and business needs (15 points)
Provide evidence of working with clients transparently to show clarity over spend/hours worked and delivering excellent value for money (15 points)
Provide an example of where you have co-located with a team – either at client-site or in your offices (this could be on a part-time basis) (10 points)

Payment approach

Fixed price

Additional assessment methods

Case study
Reference

Evaluation weighting

Technical competence

60%

Cultural fit

20%

Price

20%

Questions asked by suppliers

1. Are you able to provide a list of all the digital products that are to be tested? If any require login credentials, can you supply those? Can all the products be accessed remotely?: We expect to include the following products: www.kew.org, careers.kew.org, support.kew.org, powo.science.kew.org, growwilduk.com, stories.kew.org/endeavour/, endeavour.kew.org

Additionally, to be defined and agreed: kewgardens.seetickets.com
2. You refer to "compliance with the Public Sector Bodies Accessibility Regulations" and "conduct an audit against WCAG 2.1 AA" but these are not the same thing, so can you please confirm which you want.: We acknowledge that as part of the requirements of the Public Sector Bodies Accessibility Regulations that are products should meet WCAG 2.1 AA compliance, but that there are some exemptions. We need to ensure that we are compliant with the Accessibility Regulations, but we would like to audit against the full WCAG 2.1 criteria to highlight issues beyond what the Accessibility Regulations include.
3. In the report, is it sufficient to just report what is non-compliant and why it is? Or do you also want detailed information on how to fix the non-compliances, which obviously costs more.: We would expect a report to include recommendations for solutions to enable Kew to brief other parties on how to achieve compliance.
4. Is this engagement just for a single round of testing for each system? Or does it include one or more rounds of retesting until full compliance is achieved?: We would foresee the focus being on a single round of testing to complete an audit and report. Following the audit we expect to work with the appointed supplier to clarify any recommendations whilst working with our external development partners to correct issues raised to understand what resolutions will be acceptable for the criteria tested against.
5. Are you able to estimate the total number of pages that are to be tested and provide an indication of the page complexity, such as "one thing per page"?: We estimate between 20-30 pages across the products to be tested, assessing against WCAG 2.1 criteria. We would like to discuss with the appointed supplier any particular needs to include certain pages to ensure comprehensive testing and auditing.
6. Are you able to provide any other information that will help us assess the time requirement, such as screenshots or wireframes of the pages or access to the systems?: We're unable to provide screenshots, wireframes, or access to systems at this stage. We expect to include the following products: www.kew.org, careers.kew.org, support.kew.org, powo.science.kew.org, growwilduk.com, stories.kew.org/endeavour/, endeavour.kew.org. Testing between 20-30 pages across those products.
7. Do you have a preferred format for the test results? Will you want the non-compliances entered in an online bug tracking tool as well as in the report?: We would like to receive a PDF written report with a summary of any issues found with recommendations, accompanied by a more detailed audit results document that shows pass or fails against the assessed criteria. Previously we have received the audit results documentation as a spreadsheet document.
8. A WCAG audit is done by means of code inspection and user interface testing. There is no requirement to include user testing as part of an audit for WCAG compliance, and there is no benefit in doing so. If compliance with WCAG and the Public Sector Bodies Accessibility Regulations are the only objectives, why are you specifying that user testing must be included? Would you accept a proposal that does not include it?: We understand that auditing doesn't rely on including user testing. We have included user testing as part of this brief as we would like real users to be engaged as part of this work and to have feedback directly from users. We are committed to including users as part of this work and would not look to engage a supplier who can't fulfill this aspect of the brief.
9. You say you "expect the majority of work to be completed remotely away from RBG Kew's offices". What work would need to be done on-site? Would any user testing need to be done on-site?: There is no expectation to carry out any user testing on site, but we would be happy to discuss this with the appointed supplier if they felt it would be beneficial to the audit. We expect to have 2-3 meetings with the appointed supplier during the audit, which we would hope to do face-to-face (preferred) or via Skype video calls.
10. You use the phrase "desk-based research" in a few places. What exactly do you mean by that? In your questions, you ask about experience of desk-based research separately from experience of conducting WCAG audits, which implies that you think they are different things.: We define desk-based research as auditing products using appropriate tools to test against WCAG. As part of this work, we expect the appointed supplier to engage real users, rather than rely on desk-based work alone.
11. Do you require testing with assistive technologies? Testing for compliance with WCAG and the Public Sector Bodies Accessibility Regulations does not require the use of assistive technologies, but the wording of your requirements suggests you might be expecting it to be included.: We acknowledge that WCAG presents itself as technology neutral, we would like to include the use of assistive technologies as part of this audit, including with real users, to have a comprehensive review of the accessibility of the products
12. Can you tell us your required completion date for the initial testing so we can proposal a suitable timeline?: We would like the initial testing to be completed by Friday 27 March 2020, to then have a report issued by Friday 3 April 2020. We are happy to discuss timelines and what is achievable by certain dates.
13. You mentioned about an audit that already was done (as a first phase). Can you send us the results of the audit, the documentation?: We would be happy to share results for the previous audit with the appointed supplier through this tender.
14. How does the desk aspect of this relate to the last audit – is it additional, or does it include re-testing that covered previously?: This is a new audit, separate to the last audit carried out in 2019. There is no specific re-testing of issues from the last audit but inevitably there is likely to be some duplication between audits based on high usage areas of each product.
15. Is re-testing to be delivered within the 20k budget, as this is contingent on performance of the developers?: We would expect retesting where appropriate, or to discuss recommendations in order to comprehensively brief any development work.
16. Can you confirm the that tickets.kew.org/WebStore/shop/ViewItems.aspx is out of scope?: tickets.kew.org/WebStore/shop/ViewItems.aspx is not within the scope of this brief.
17. In addition to highlighting issues, are you looking to the supplier to identify proposed development solutions to achieve compliance?: We would expect a report to include recommendations for solutions to enable Kew to brief other parties on how to achieve complianc
18. Have any of the issues identified by the 2019 audit been resolved?: We believe that the majority of the issues identified by the audit in 2019 have now been corrected.
19. Do the sites in scope share designs or templates?: Each product has its own design, though there are some shared elements to ensure some consistency of Kew's brand.
20. How old are the websites?: The products are between 1-3 years in age.
21. Are you able to share a copy of the report that was produced by the 2019 accessibility audit?: We would be happy to share results for the previous audit with the appointed supplier through this tender.
22. Do the sites in scope share the same technology?: The products are built using a range of technologies - Drupal 8, Frog LMS, Agresso e-Recruiter, Shorthand, and custom-built and managed CMSs.
23. What is the mix of internal development teams and external suppliers responsible for resolving the issues?: powo.science.kew.org is supported by an internal development team. All other products are supported by multiple external development teams.
24. Location confirmation: Royal Botanic Gardens, Kew, is based in Kew, Richmond.
This is the location for the work.
(South West London)

Can we store analytics cookies on your device?

Awarded to Zoonou Limited