Government Website Accessibility and Performance Observatory with Monthly Public Reports

The problem: essential websites nobody measures

Board exam results, university admissions, driving licences, tax filing, utility bills, passport appointments: more and more of daily life in Pakistan and across South Asia runs through public sector websites. When these sites are slow on a phone, unusable with a screen reader, missing Urdu, or showing a certificate warning, people give up, pay an agent, or travel to an office instead.

Problems like these are rarely visible to the departments that run the sites. There is no regular, public, comparable measurement, so there is no pressure to improve and no way to see whether things are getting better.

What already exists and the gap

• The WebAIM Million is a yearly report on the accessibility of the top one million home pages worldwide. It is the best-known study of its kind, but it covers popular sites globally, not a country's public sector.
• Lighthouse, PageSpeed Insights and WAVE can check any page, one at a time, by hand.
• Some governments publish their own accessibility monitoring, but many countries, including Pakistan, have no public, regular measurement of their own sites that we could find.

The gap is a small, repeatable, open observatory for one country's public sector sites, run monthly, with history, open data and fix tips.

Inspiration

The WebAIM Million 2025 report found detectable WCAG 2 failures on 94.8% of the top one million home pages, an average of 51 errors per page, and showed that six common issues (low contrast text, missing alt text, missing form labels, empty links, empty buttons and missing language declarations) account for 96% of detected errors. Your project uses the same approach (automated checks at scale, with clear reporting of the most common issues) for a much smaller, more important set of sites, and adds performance and security checks that matter to users on cheap phones.

What you build

• Citizens and journalists look up a department's site and see how it scores and whether it improved.
• Developers and IT officers in government get a report of their site's issues with plain-language fixes and links to guidance.
• Researchers and advocacy groups download the open data.

The technically interesting part

This is a beginner project, but doing it well still takes care:

• Building the list. Collect official public sector sites from directories and official links, record which department runs each one, and remove duplicates and dead sites.
• Fair testing. Use the same browser version, the same throttled mobile profile and the same time window for every site, and run each test more than once to reduce noise.
• Key pages, not just home pages. People rarely need the home page. For each site, pick two or three pages that matter, such as a results page or an application form.
• Language checks. Detect whether an Urdu or other local-language version exists, and whether pages declare their language and direction correctly.
• Honest presentation. Automated tools catch only some accessibility problems. Say so clearly on every page, and avoid labelling a site "accessible" because it has no detected errors.

How to evaluate it

• Coverage: number of sites and pages scanned successfully each month, with reasons for failures.
• Stability: score variation between repeated runs of the same page.
• Accuracy: manually check a sample of 20 reported issues and record how many were real.
• Usefulness: contact a few site owners or IT officers with their report and record whether anything changed in the next scan.

Suggested plan

• Weeks 1 to 3: build and clean the site list, choose key pages.
• Weeks 4 to 6: scanning scripts for accessibility, performance and security checks.
• Weeks 7 to 9: database, history and the scheduled monthly run.
• Weeks 10 to 12: public site, league table, per-site pages and open data downloads.
• Weeks 13 to 15: accuracy checks, outreach, write-up and demo.

Path to a product

Public bodies, donors and digital rights groups all want evidence on the quality of digital public services. The observatory can grow into a yearly report, a paid audit service for departments, or a project funded by a civic technology grant. It is also a strong, very visible portfolio piece for frontend, QA and accessibility roles.

Scope warning

Scan politely: low request rates, scheduled runs, a clear user agent with contact details, and only public pages. Never try to log in or submit forms on government systems. Present results as automated findings with known limits, not as a final judgement on any department.

Learn what you need on Sefism

• QA and test automation roadmap: automated checks and reliable test runs.
• How to Meet WCAG 2.2: the rules behind each accessibility finding.
• Learn Accessibility: writing fix tips site owners understand.
• web.dev: performance metrics and how to explain them.
• Data analytics roadmap: presenting results fairly with history and context.
• Which final year project will actually help me get a job?: why a public, measurable project stands out.

Get help with this idea

The risk is a scan that is noisy, unfair to some sites or ignored by the people who could fix things. Tauseef can help you choose the site list and key pages, set up fair testing and plan how to share results. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session