The City of Toronto is committed to making all digital services and information accessible to everyone. The Digital Accessibility Standard outlines the City’s requirements for digital accessibility in technology, content and service delivery.

This standard supports a commitment to digital accessibility:

This standard applies to the development of all applications and digital assets, whether developed in-house or by third parties, including:

  • Public-facing web-based applications, websites and content accessed directly through toronto.ca.
  • Internal-facing web-based applications and content, such as Intranet pages
  • Software as a Service (SaaS) application(s) purchased or deployed at or by the City.
  • All digital documents and assets, such as PDFs, Word documents, Excel spreadsheets, PowerPoint presentations and any other digital content developed or used by the City.

All City information and technology assets must comply with this standard to ensure digital accessibility.

Term Definition
Accessibility for Ontarians with Disabilities Act (AODA) An Ontario law mandating that organizations must follow standards to become more accessible to people with disabilities. The Act recognizes the history of discrimination against people with disabilities and sets out a process for developing, implementing and enforcing accessibility standards to make Ontario more accessible and inclusive by 2025. The goal is for Ontario to be fully accessible by 2025. This legislation applies to all levels of government, private sectors and non-profits. The City’s AODA requirements are outlined in the Corporate Accessibility Policy.
Application Computer program or set of programs designed to help people perform an activity.
Automated Tools Software solutions used to quickly scan and evaluate websites, applications, or digital documents for accessibility issues against standards such as WCAG 2.1 and AODA. These tools can efficiently identify common errors (e.g., missing alt text, low color contrast, improper heading structure), integrate into development environments and CI/CD pipelines and provide reports to support accessibility compliance. While effective for detecting many issues, automated tools cannot capture all accessibility barriers, particularly those requiring human judgment (such as content clarity, logical reading order, or meaningful alt text).
Digital Accessibility The systematic approach to designing and developing websites, tools, technologies and electronic documents (including PDFs, Word and PowerPoint files) to ensure they are accessible to individuals with disabilities. This involves creating digital content that allows all users to effectively perceive, understand, navigate and interact with the web and its associated documents, ensuring an inclusive and seamless user experience.
JAWS (Job Access with Speech) A widely used commercial screen reader for Windows that provides speech and Braille output for users with a visual disability enabling navigation and interaction with digital content.
Manual Tools Testing methods and assistive technologies used by accessibility specialists or end-users with disabilities to validate digital content. Manual tools include screen readers (e.g., JAWS, NVDA, VoiceOver), screen magnifiers, keyboard-only navigation and guided accessibility testing platforms. Manual testing is essential to confirm real-world usability and to identify issues not detectable through automation, ensuring that digital experiences are accessible, perceivable and operable by people with diverse abilities.
NVDA (Non-Visual Desktop Access) A free, open-source screen reader for Windows that offers speech and Braille output, supporting web browsing and document reading for individuals with vision-related disabilities.
PDF/UA (PDF/Universal Accessibility) An ISO standard (ISO 14289) specifying requirements for accessible PDF documents, ensuring proper tagging, structure and semantic information so assistive technologies can accurately interpret content.
Portable Document Format (PDF) A file format developed by Adobe that preserves document formatting and enables secure, platform-independent sharing of documents widely used for digital content distribution.
VoiceOver A built-in screen reader available on Apple platforms (macOS, iOS and iPadOS) that uses speech and Braille to help users with visual-related disabilities interact with on-screen content.
Voluntary Product Accessibility Template (VPAT) A document template used by technology vendors to describe how their products or services meet accessibility standards, forming the basis for an ACR.
Web Content Accessibility Guidelines (WCAG) A set of standards developed by the World Wide Web Consortium (W3C) that provide guidance on making web content, digital content and software applications accessible to people with disabilities. These guidelines help ensure that websites and applications are easy to use for everyone, including users with visual, auditory, physical, speech, cognitive and neurological related disabilities. WCAG is divided into three levels: A, AA and AAA, with AA being the most widely adopted standard, as it strikes a balance between accessibility and feasibility, ensuring that web content is accessible to a broad range of users.

The City of Toronto is committed to ensuring that all our digital services and information are accessible and usable by residents, businesses, visitors and City staff.

To meet these needs, the City is committed to going beyond the minimum compliance requirements for digital accessibility under the Accessibility for Ontarians with Disabilities Act (AODA), including:

Accessibility Conformance

All websites, digital applications and digital content must conform to WCAG 2.1 or higher meeting both Level A and AA requirements. Additionally, documents created in Word, Excel and PowerPoint should be built using accessible templates and verified with built-in accessibility checkers. For PDFs, they must conform to the PDF/UA and WCAG standards.

Scope & Applicability

This applies to public-facing and internal-facing websites, digital content and City applications, including third-party applications that deliver services and information on behalf of the City.

Accessibility and usability are the combination of a number of factors (e.g., User Experience (UX) Design, Content Readability, Assistive Technology Compatibility, Responsive Design, Interactive Elements, Error Prevention and Recovery, Feedback and Support, Performance and Load Time, Legal and Ethical Considerations) and not simply about compliance to legislative requirements.

To allow for a successful implementation of sustainable and scalable accessibility best practices in web development, design and content structure, where applicable, the City will ensure that all web-based services, digital assets and information reflect the City of Toronto’s accessibility best practices.

Validation

Validation of accessibility must be conducted throughout various stages of the project such as design, development and quality assurance (QA) to ensure the product complies with accessibility standards and meets the needs of all users.

Validation must be performed through a structured testing process that combines automated and manual methods. Automated tools quickly identify common accessibility issues, but they cannot catch every potential problem; therefore, manual testing by accessibility experts is required to ensure full coverage.

Supplier Product or Solution’s Accessibility Conformance Report (ACR)

All third party supplier(s) must provide a completed Accessibility Conformance Report (ACR), typically in the form of a Voluntary Product Accessibility Template (VPAT), to document whether the product or solution meets or does not meet WCAG 2.1 guidelines. Note that having an ACR does not guarantee full compliance with all guidelines.

Requirements for ACR

  • The ACR should be completed by a third-party digital accessibility specialist or an organization to ensure impartial and accurate reporting.
  • The ACR must be recent (preferably within 1 year or aligned with the last major product update).
  • The supplier must outline their remediation plan, including timelines for addressing any identified accessibility issues.

Approval Process

The Digital Accessibility Team provides final approval of applications based on accessibility review results. Applications will be assigned one of the following statuses:

  • Not Reviewed (default): No accessibility review has yet been conducted.
  • Approved: The application has no known outstanding issues and it meets all WCAG 2.1 A and AA guidelines.
  • Conditional Approval: The application has some outstanding issues, but none are High, Critical, or Blocker. Other factors considered include the number of users impacted and if technical alternatives are available from other sources. A remediation timeline for the remaining issues must be provided.

Record Keeping

All business applications and their accessibility review outcomes must be documented and retained to provide evidence of compliance. Accessibility review outcomes constitute a business record providing evidence of compliance and need to be captured and retained by application owners. For each application, the following metadata are recorded where applicable:

  • Review status (Not Reviewed, Approved, Conditional Approval)
  • Date of review
  • Target remediation date – if applicable
  • Link to accessibility review intake

This standard is developed and maintained by the City of Toronto to ensure that accessibility requirements are applied consistently across all digital platforms.

The City reviews this standard annually to align with legislative changes, industry standards and evolving accessibility practices.