Digital Accessibility
Strategy and Process

KDL's updated approach

Alessandra Esposito, Geoffroy Noël, Tiffany Ong

Agenda

Historical context (5min)

Reasons for change (10min)

Updated approach (15min)

Questions (30min)

Structure

• Introduction/Agenda (AE 2min)
• Historical context (GN 3min)
• Updated approach (GN 4min)
• Strategy (GN 3min)
• Process
  • Overview (4 mins)
  • Steps 1-4 (TO 12mins)
• Questions

History

• 2019: KDL's began an approach to accessibility
• 2020 early: Designer hired for 6 months, and Intern
• 2020 late: Review meetings
• 2020 late: SLA approach
• 2021 mid: "The road to a more inclusive web" blogpost

2020 late Review meeting

Approximately 10 members involved over a 12 month period (2 team members working solely on accessibility for 6 months)

Time

• Legacy/post projects took 3-5 times longer
  • difficult setup
  • tedious recording
• Active projects seemed to take much less time
• But difficult to know how much accessibility in active projects really took
  • some projects did not have a separate accessibility task to log time
  • assess and fixes often recorded within requirement tasks
  • mainly statement time was recorded

Example of a spreadsheet to record all issues and fixes

screenshot from [spreadsheet]

It would take us 4-5 years to complete with 70+ more post projects

Actions

• Double checked legal compliance
• Not legally required
• But KDL still kept an overall commitment
• Added Accessibility to SLA

2020 late:

An attempt to list down process but was not taken forward

Learnings

• Non-adaptive, rigid approach
• Lack of open dialogue and collaboration
• Focus on compliance
• Complex official resources
• Insufficient internal documentation
• Disproportionate work distribution
• Mismatched responsibilities
• Uneven knowledge and understanding
• Limited support

Accessibility

A very quick introduction

Reference: Adaptation from Microsoft’s Inclusive Design Toolkit and
Booking.com

WCAG

The Web Content Accessibility Guidelines (WCAG), developed by the World Wide Web Consortium, are technical standards that help make the digital world accessible to people with disabilities. Numerous stakeholders, including disability advocacy groups, government agencies, and accessibility research organizations, collaborated to create these guidelines, which are considered the universal standard for digital accessibility.

• WCAG Versions 1.0 (1999), 2.0 (2008), 2.1 (2018) and 2.2 (2023)

• Three Levels of WCAG Conformance: A (minimum), AA (mid), and AAA (highest)

Reference: https://www.wcag.com/resource/what-is-wcag/

Reference: Adaptation from and more examples at gov.uk

Observations

All or nothing approach

• Avoidance

  • Feasibility - Reasons were given that accessibility wasn't needed in project requirements

  • Evolutionary Development - Not prioritised, often left to the end where there would be no time to work on

• Inconsistent outputs

  • very different processes

  • dependant of who was on the project

Updated approach

• 2023 early: Strategy and Process aligned with SDLC
• 2023 late: New team formed Project Review Record
• 2024: trialled 3 projects -
  Living with machines, Alice Thornton, King's Past
• 2025 mid: Post-project review
• 2025 mid: Blogpost and Slides

Plan

Strategy

Our objective is to cultivate a digital environment that enhances usability, inclusivity, and full compliance with accessibility standards. The introduction of new government regulations in 2018 prompted us at King’s Digital Lab to formally strengthen our accessibility approach.

Through continuous iterations, our current strategy aims to reach and benefit the broadest possible audience, supporting accessibility in a sustainable, scalable way, integrating it comprehensively with our Software Development Life Cycle (SDLC) and Agile methodology. We actively research the latest resources and seek user feedback to understand the needs and challenges with our digital offerings. This ongoing engagement informs our improvement updates to ensure alignment with evolving best practices and accessibility standards.

Process

Key roles and general responsibilities

• Analyst (A)

• Engineer (E )

• UI/UX Designer (U)

• Project Manager (PM)

• Research team (RT) [project partners]

• Sysadmin (S)

• (U): Ensure accurate level of accessibility in requirements, process and deliverables

• (U) - Design accessible interfaces (contrast, layout, navigation).

• (U) - Plan accessibility in timelines, ensure accessibility is tracked and reviewed

• (U) - Identify and report users and requirements that need accessibility considerations. Ensure content is accessible

• (U & E ) - Code with accessibility standards (WCAG) and run automated accessibility tests

• (U) - Responsible for accessibility statement

Reference: https://www.ontario.ca/page/inclusive-design-toolkit

Reference: University of Melbourne

• Analyst (A)

• Engineer (E )

• UI/UX Designer (U)

• Project Manager (PM)

• Research team (RT) [project partners]

• Sysadmin (S)

• (A): Ensure accurate level of accessibility in requirements, process and deliverables. Responsible for accessibility statement

• (E ) - Code with accessibility standards (WCAG) and run automated accessibility tests

• (U) - Design accessible interfaces (contrast, layout, navigation).

• (PM) - Plan accessibility in timelines, ensure accessibility is tracked and reviewed

• (RT) [project partners] - Identify and report users and requirements that need accessibility considerations. Ensure content is accessible

• (S) - Support infrastructure that enables accessible content and tools.

4 steps to implement accessibility within our Software Development Life Cycle (SDLC)

1. Requirements [Feasibility]
2. Scope [Kick off]
3. Assess/Fix [Evolutionary Development]
4. Documentation [Evolutionary Development]
5. SLA [Post-project]

1. Requirements [Feasibility]
   Lead A, Collaborate E U, Consult S R
2. Scope [Kick off]
   Lead A, Collaborate E U, Consult R
3. Assess/Fix [Evolutionary Development]
   Lead E U, Collaborate A
4. Documentation [Evolutionary Development]
   Lead A, Collaborate E U, Consult PM R

1. Requirements

[Feasibility]

Lead A, Collaborate E U, Consult S

Determine the MoSCoW Digital Accessibility requirement needed during Feasibility

(Questionnaire could be given to partners at this stage)

(Estimates need to be updated to adapt for different project budgets/timelines)

MUST (M)

• meet WCAG A/AA criteria for the majority of components (few/none will not meet)

• perform specific accessibility assessments during evolutionary development

• produce a public accessibility statement and update it at each deployment

• Estimate 4 days = A 1 | E 1.5 | U 1.5

  ---

  ✔ Has more than 5 users

  ✔ Has 1st party apps/platforms

  ✔ Has only non-complex components

  e.g. Layers of Vision, KDLweb,  CultureCase ~28h

Use in feasibility:

KDL will look to meet WCAG A/AA criteria for the majority of components with specific accessibility assessments integrate them into the evolving solution aiming to update at each deployment and produce a public statement.

MUST (M)

SHOULD (S)

• meet WCAG A/AA criteria for some components (some might not meet)

• perform specific accessibility assessments during evolutionary development

• produce a public accessibility statement and update it at each deployment

• Estimate 3 days = A 0.6 | E 1.2 | U 1.2

  ---

  ✔ Has more than 5 users

  ✔ Has 1st party apps/platforms

  ✘ Not only non-complex components

  e.g.  Radical Translation (Data visualisation) 18-20h (incl fixes), Alice Thornton (Digital Edition), Field (Game)

Use in feasibility:

KDL will look to meet WCAG A/AA criteria for some components with specific accessibility assessments integrate them into the evolving solution aiming to update at each deployment and produce a public statement.

SHOULD (S)

COULD (C)

• integrate basic digital accessibility requirements based on individual knowledge into the evolving solution

• not perform specific accessibility assessments

• produce a public accessibility statement and update it at each deployment

• Estimate 1 day = A 0.2 | E 0.4 | U 0.4

  ---

  ✔ Has more than 5 users

  ✘ Not using only 1st party apps/platforms

  e.g. Living with Machines ~6h

Use in feasibility:

KDL will look to meet the basic digital accessibility requirements and integrate them into the evolving solution aiming to update at each deployment and produce a public statement.

COULD (C)

WON'T (W)

• integrate basic digital accessibility requirements based on individual knowledge into the evolving solution

• not perform specific accessibility assessments but scope still needed

• not produce a public accessibility statement

• Estimate 0.3 days = A 0.1 | E 0.1 | U 0.1

  ---

  ✘ No more than 5 users

  e.g. Crossreads A, PiNiM ~0h

Example from TIBBL Requirement Table

Example from Slavery & Warfare Requirement Table

2. Scope

[Kick off]

Lead A, Collaborate E U, Consult R

Discuss with project team and determine what will be assessed during project Kick off

• Goals: Discuss and agree on assessment goals. Are we aiming for a complete site audit or specific sections? Decide on full-site vs. targeted audit, and specify the compliance level (A, AA, AAA) to align with organisational and legal requirements.

• Target Users: Brainstorm and list user profiles, including those with visual, auditory, motor, and cognitive disabilities. Discuss the specific accessibility needs these users may have, identify any assistive technologies (e.g., screen readers, magnifiers) they might use.

• User Journeys: Map and prioritize key user journeys, such as searching an archive, filtering data points. Ensure each journey is accessible end-to-end. Prioritize which flows to focus on based on user importance and frequency of use.

• Pages and Features: Identify high-traffic pages, core user flows (e.g., checkout, login), and key interactive elements (e.g., forms, tables, multimedia). Create a checklist for multimedia (videos with captions), dynamic elements (pop-ups, forms), and images (alternative text).

• Devices, Operating Systems, and Browsers: Identify the primary devices, OS, and browsers based on to reflect real-world usage, analytics data or user feedback. Cover popular browsers like Chrome, Firefox, Safari, and Edge, focusing on both the latest and older relevant versions.

• Content and Formats: Review and list content types for accessibility checks, including text, images, multimedia, and interactive components.

• Third-Party Components: Identify any third-party integrations, such as chat or map widgets, embedded videos, or social media feeds. Determine which components need specific checks or alternative solutions.

• Technical Constraints: Discuss any limitations posed by frameworks (e.g., R/eact, Angular) or the CMS that might impact accessibility implementation.

• Responsiblities by Role: List more specific role responsibilities. Decide how much collaboration or dependences will be needed.

• Pages/Outputs: List all the urls to test and statement link

• Schedule: Confirm how often or when to work on certain parts. e.g. testing, statement updates

Example from Living with Machines

Example from Alice Thornton

Scope table template

(still in progress)

The scope should be checked at different points in the project, especially if there are changes to the requirements, to see if it still fits.

Time logging

It's important to get an overview across projects over time for better estimation and to know which areas to improve.

Ensure tasks are set up in CU and split time estimates into subtasks in the main RQ task:

• 2: Scope

• 3: Assess and fix
  If done within the Evo Dev process, estimate roughly how long you took e.g. if you spent 5h developing or designing and did a few checks along the way, you might log 1h

• 4: Documentation
  First deployment even on stg/dev should have the barebones statement

Example from King's Past

3. Assess/Fix

[Evolutionary Development]

Lead E U, Collaborate A

All assessment and fixes should be integrated seamlessly, continuously when designing and developing within the evolutionary development work, ensuring checks are done before any deployment/increment.

• Assess

  • Automated Testing: Use automated accessibility tools (like WAVE, Axe, WebVal or Lighthouse) to identify common issues, such as missing alt text, insufficient colour contrast, or missing form labels. These tools provide a broad initial scan but typically don't capture all accessibility barriers.

  • Manual Testing: Conduct manual checks to identify issues automated tools may miss, such as keyboard navigation functionality, screen reader compatibility, dynamic content accessibility (e.g. hover states, text over image). This stage often includes testing with assistive technology like screen readers (e.g., JAWS or NVDA) and magnifiers.

  • Stand alone assessments (fixes done separately) should be documented in CU.

• Fix when issue is found.

  • Any issues that cannot be fixed should be recorded directly to the statement.

  • Tools and methods should also be recorded in the statement.

Example Colour Contrast Findings from Alice Thornton

Find the colours used in the code or take a screenshot and colour pick it in a tool like Photoshop or similar alternatives like pixlr. Then put the hex colours in a tool like https://webaim.org/resources/contrastchecker/

Example Colour Contrast Findings from Radical Translations

Example tool: Figma Color Contrast Checker

4. Documentation

[Evolutionary Development]

Lead A, Collaborate E U, Consult PM R

• Statement

  • First deployment should have the barebones statement

  • Refer back to Scope table to check if decisions/level planned at the time match delivered solution

  • Issues that are not fixed should be recorded

  • Tools and methods should be recorded

Adapted gov.uk template statement from COTR

Issues using the gov.uk template

• took a long time to fill in
• difficult to understand

Adapted minimal statement from King's Digital Lab highlighting repetition and Date title

minimal generator template

• shorter time
• lots of repetition

• Recent KDL examples:

  • King's Past, Radical Translation, King's Digital Lab (minimal generator)

  • Alice Thornton (gov.uk template)

  • Living with Machines (Very minimal)

• External examples:

  • National Archives

  • UKRI

  • JISC

The diagram maps out the basic overview of the 4 steps

Conclusion and Actions

• Blogpost to publish
• KDL Team to feedback on process
• DA team to review in 6 months?
• SLA process not yet looked at
• Decision to carry on or change strategy

Internal References:

• Process Document draft versions and references in Sharepoint

• Strategy 2022 in Sharepoint

• Diagram versions in Miro

• Digital Accessibility Project Review Record

• SharePoint Accessibility reference index

• Previous KDL approach The road to a more inclusive web: The state of digital accessibility at KDL

• Digital Accessibility Post-Project Review Report

End

Digital Accessibility Strategy and Process documentation in Clickup