Accessibility Standards

Introduction

1.1.1 Purpose

This standard provides a uniform framework for ensuring that all websites, web applications and digital services produced or commissioned by Malawi’s ministries, departments and agencies are accessible to people of all abilities. It is grounded in WCAG 2.2 and informed by regional standards to foster inclusive design practices. The purpose is to remove barriers to information and services, ensure equal participation, and encourage universal design.

Scope of Application

The standard discussed herein apply to:

All public‑facing and internal websites, portals and web‑based applications developed, funded or hosted by Malawi’s government entities.

Mobile applications and progressive web apps developed for government services.

Procurement of third‑party digital products, including outsourced web development and software licenses. Vendors must demonstrate compliance with this standard and provide an accessibility conformance report

Objectives

1.3.1 Primary Objectives

• Achieve Level AA conformance: Ensure all digital platforms meet WCAG 2.2 at Level AA by default. Where feasible, strive to meet Level AAA requirements, recognizing that Level A criteria are the minimum baseline.
• Promote universal design: Integrate inclusive and universal design principles from project inception to accommodate diverse user needs, reflecting Kenya’s KS 2952 standard and the CRPD’s emphasis on accessibility.
• Address local context: Incorporate local languages (e.g., Chichewa and Malawian Sign Language) and consider low‑bandwidth and device constraints to ensure equitable access across Malawi.
• Support continuous improvement: Establish processes for training, testing, monitoring and updating accessibility practices to align with evolving standards and technologies.

1.3.2 Key Performance Indicators

Progress under this standard should be measured through a set of practical indicators. These include the percentage of government digital platforms that achieve WCAG 2.2 Level AA compliance, the number of platforms undergoing regular accessibility audits, the time taken to remediate critical accessibility issues, the proportion of relevant staff and vendors trained on accessibility requirements, and the volume of accessibility-related user feedback received and resolved. Together, these indicators provide a practical way to monitor adoption, measure improvement, and strengthen accountability over time.

Standards

WCAG 2.2 defines three conformance levels: A, AA and AAA. All websites, web applications, and digital services must comply with the Web Content Accessibility Guidelines (WCAG) 2.2, at a minimum Level AA standard.

Level A (Minimum Conformance)

Level A shall be treated as the minimum entry point for accessibility. At this level, digital platforms must remove the most immediate barriers that prevent people with disabilities from accessing content and services. At a minimum:

Non-text content, such as images and icons, must have text alternatives.

Audio and video content must include captions, transcripts, or other equivalent alternatives where required.

Core functions must be usable by keyboard only, without requiring a mouse or touchscreen.

Content must not flash in a way that could cause seizures or other harm.

Level AA (Mandatory for Malawi)

Level AA shall be the required standard for all Malawi Government websites, web applications, and digital services. It builds on Level A and must be used to ensure that services are accessible in a practical, reliable, and consistent way for the widest range of users. In addition to meeting all Level A requirements, digital platforms must:

Use sufficient colour contrast between text and background so content can be read more easily.

Present content clearly across different screen sizes and orientations.

Use clear headings, labels, and instructions to support navigation and understanding.

Ensure keyboard users can always see which element is currently selected or in focus.

Make buttons, links, and other interactive elements large enough, or spaced well enough, to be selected easily.

Provide alternatives to actions that rely on dragging.

Avoid requiring users to enter the same information more than once in the same process where this can be avoided.

Make authentication and login processes accessible, including for users with cognitive or memory-related difficulties.

Level AA is the minimum compliance level that all government digital platforms should achieve and maintain.

Level AAA (Enhanced Accessibility)

Level AAA should be treated as an enhanced standard to be applied where practical, especially for high-impact or high-priority public services. It introduces stronger accessibility measures that further improve usability for a wider range of users. Where feasible, institutions should:

Apply stronger contrast standards to improve readability.

Provide sign-language interpretation for pre-recorded video content.

Include additional measures that support users with cognitive, learning, or communication difficulties.

Go beyond minimum compliance to improve clarity, comprehension, and ease of use.

Level AAA is not required in every case, as some of its requirements may not be practical for all content types or services. However, institutions should adopt Level AAA measures wherever they are achievable and where they add clear public value.

Principles & Guidelines

All digital platforms shall be designed and maintained in line with the four main accessibility principles: Perceivable, Operable, Understandable, and Robust (POUR). These principles set the foundation for accessible design and development. Compliance shall not be limited to technical checks alone; each principle must be applied in a practical way that improves access and usability for all users.

1.5.1 Perceivable

Information and interface elements must be presented in ways that users can detect and understand, regardless of disability or device limitations. To meet this requirement:

Provide text alternatives for non-text content, including images, icons, charts, diagrams, and interface controls.

Provide captions for video content and transcripts for audio content. Where feasible and appropriate, provide sign-language interpretation for important multimedia content.

Use proper structure, including headings, lists, labels, and landmarks, so that content is presented in a meaningful order and can be understood by assistive technologies.

Do not rely on colour, shape, size, or visual position alone to convey meaning or instructions.

Maintain sufficient contrast between text and background, using at least 4.5:1 for normal text and 3:1 for large text.

Ensure text can be resized up to 200% without loss of content or functionality.

Avoid using images of text unless there is a clear and necessary reason.

Ensure layouts adapt properly to smaller screens, zoomed views, and different device orientations.

Optimise content for low-bandwidth environments by reducing page weight, compressing images, avoiding unnecessary auto-play media, and using efficient loading techniques where appropriate.

1.5.2 Operable

Users must be able to navigate and interact with all content and functions in a range of ways, including without a mouse. To meet this requirement:

Ensure all functionality can be accessed and used by keyboard alone.

Provide a clear and visible focus indicator so users can always identify which element is currently selected.

Do not require dragging, swiping, or other complex gestures where a simpler alternative can be provided.

Ensure buttons, links, and other interactive elements are large enough, or spaced well enough, to be selected accurately. As a minimum, interactive targets should generally meet the 24 × 24 CSS pixel requirement or equivalent spacing.

Do not include content that flashes more than three times per second.

Provide clear navigation aids, including skip links, descriptive page titles, headings, and consistent menus.

Ensure users can tell where they are within the website or service at all times.

Place support options, such as FAQs, contact details, or live help, in a consistent location across pages.

Give users sufficient time to read and complete tasks, and provide options to extend or manage time limits where needed.

1.5.3 Understandable

Content and interactions must be clear, predictable, and easy to follow. Users should be able to understand both the information presented and how to use the service. To meet this requirement:

Use clear, concise language wherever possible.

Identify the main language of each page and indicate any changes in language within the content.

Ensure navigation, menus, and interface components behave consistently across pages and screens.

Avoid unexpected changes in context, such as opening new windows or changing page content without warning.

Clearly label all form fields, controls, and instructions.

Provide helpful validation, clear error messages, and guidance on how to correct mistakes.

Avoid requiring users to enter the same information more than once in the same process where this can be avoided.

Ensure authentication processes are accessible and do not rely only on memory, complex problem-solving, or inaccessible CAPTCHA challenges.

Provide help and support content in clear language and make it easy to find consistently throughout the service.

1.5.4 Robust

Content must be built in a way that allows it to work reliably across current and future browsers, devices, and assistive technologies. To meet this requirement:

Use valid, standards-based HTML and apply ARIA only where necessary and correctly.

Ensure code is structured so that assistive technologies can correctly identify elements, roles, states, and relationships.

Ensure important status updates, alerts, form messages, and modal content are properly communicated to assistive technologies.

Test digital platforms across commonly used browsers, operating systems, screen readers, and other assistive tools.

Avoid unnecessary reliance on vendor-specific features or code that may reduce compatibility.

Set the correct language attributes for each page and for sections of content where the language changes, so assistive technologies can interpret and pronounce content correctly.

Special Considerations

1.6.1 Language

Local languages: Where applicable, provide core content in Malawi’s official and widely spoken languages, such as Chichewa, to reach users with limited English proficiency. Use plain language and visual aids to support users with low literacy levels.

Sign‑language support: UNICEF’s guidance stresses that national sign languages are vital for deaf children’s cognitive and psychosocial development and that digital materials should incorporate sign language. Include Malawian Sign Language (MSL) interpretation or provide links to MSL videos for key multimedia content. Synchronise sign‑language videos with captions and transcripts.

Localization beyond translation: Adapt interfaces, voice prompts, and assistive technologies to local cultural and linguistic contexts. The Mada Centre notes that failure to localise assistive technology can exclude non‑English speakers and those with diverse accents.

1.6.2 Low Bandwidth & Device Constraints

• Optimise performance: Recognise that many users in Malawi experience download speeds below 10 Mbps. Use compressed images (e.g., WebP), minified code, caching and lazy loading; prioritise essential content and avoid auto‑playing media.
• Provide alternatives: Offer text‑based or low‑resolution alternatives to video and high‑bandwidth features; when video is essential, employ adaptive streaming and let users choose quality levels.
• Offline access: Implement Progressive Web Apps (PWAs) or service workers to enable offline use and minimise data consumption.
• Device compatibility: Design for low‑end smartphones and feature phones; avoid heavy frameworks and excessive animations that could slow down or crash older devices.

Implementation Strategy

1.7.1 Procurement Strategy

• Accessibility clauses: Include clear accessibility requirements in all procurement contracts for digital products. Require vendors to provide a VPAT or similar conformance report demonstrating WCAG 2.2 Level AA compliance.
• Vendor evaluation: Assess proposals based on accessibility features and prior experience; prefer suppliers who demonstrate commitment to inclusive design.

1.7.2 Design and Development

• Embed accessibility: Apply the POUR principles and local considerations at every stage of design and development. Use semantic HTML, ensure keyboard navigability, provide alt text, captioned videos and sign‑language support, and optimise performance.
• Involve users: Co‑design with persons with disabilities and local experts to ensure solutions address real‑world needs; conduct usability testing with diverse participants.

1.7.3 Continuous Improvement

• Feedback loops: Establish mechanisms for users to report accessibility issues. Monitor feedback and incorporate improvements into iterative updates.
• Policy updates: Review and update this standard as WCAG evolves or new regional laws emerge. Attend regional conferences (e.g., Inclusive Africa) to stay current with best practices.

Training and Awareness Programs

• Mandatory training: Provide regular training for designers, developers, content editors, project managers and procurement officers on WCAG 2.2, inclusive design, local language considerations and low‑bandwidth optimisation.
• Capacity building: Offer advanced workshops on assistive technology, sign‑language integration and user testing. Encourage professional certification in accessibility.
• Awareness campaigns: Promote accessibility awareness across government and society, highlighting the benefits and sharing success stories to foster a culture of inclusivity.

Testing and Validation

• Integrated testing: Perform accessibility testing at design, development and deployment stages using automated tools (e.g., WAVE, axe, Lighthouse) and manual testing. Automated tools can identify many errors, but manual testing with keyboard navigation and screen readers (such as NVDA or JAWS) is essential.
• User involvement: Include people with disabilities in usability testing to identify barriers that automated tools may miss. Test across browsers, operating systems and devices, including low‑end smartphones.

Third‑party audits: Engage independent experts to conduct periodic accessibility audits. Address identified issues promptly and update conformance reports.

Conclusion

Adopting and enforcing this accessibility standard will transform Malawi’s digital landscape. By aiming for WCAG 2.2 Level AA conformance, integrating local languages and sign‑language support, and optimising for low‑bandwidth environments, government services can become truly inclusive. These measures will enhance user satisfaction, strengthen legal compliance, and support Malawi’s commitment to the rights of persons with disabilities and universal access to information. Continuous training, testing and collaboration with stakeholders are essential to realise this vision and ensure that digital platforms serve all citizens equally.