Urdu and RTL Accessibility Linter for Nastaliq Web Pages and Government Forms

The problem: Urdu pages that screen readers cannot read

Millions of people in Pakistan read Urdu more comfortably than English, and many of them are blind, have low vision or have low literacy and rely on screen readers or text-to-speech. Government notices, university admission forms and bank pages increasingly offer an Urdu version, but it is often built as an afterthought. Common faults include pages marked lang="en" while the text is Urdu, so the screen reader reads Urdu letters with an English voice or skips them; Urdu text pasted as an image of Nastaliq script because the developer could not get the font to work; forms whose labels are Urdu while error messages are English; and left-to-right layouts with Urdu text squeezed in, so reading order and keyboard focus jump around.

Each of these makes the page useless to someone using assistive technology, and none of them is caught by the tools developers already run.

What already exists and the gap

• axe-core, WAVE and Lighthouse check general WCAG rules such as contrast, labels and alt text. They check that a lang attribute exists, not that it matches the text.
• The W3C Urdu Layout Requirements and Urdu Gap Analysis documents describe what browsers and pages need to do for Urdu, but they are reading material, not a checker.
• Manual audits by accessibility consultants are thorough but rare and expensive for public bodies.

The gap is an automated checker that understands Urdu specifically: script detection, direction, Nastaliq fonts, mixed Urdu and English content and how screen readers actually behave with it.

Inspiration

The W3C Internationalization working group publishes Urdu Layout Requirements and an Urdu Gap Analysis, which list how Urdu text should be handled on the web, including Nastaliq rendering, bidirectional text and numerals. This project turns the parts of those documents that can be checked by a machine into rules, and adds the screen reader behaviour that students can test themselves.

What you build

• Developers run one command against a URL or a whole site and get a report of Urdu-specific faults with the element, the rule and a suggested fix.
• Testers use the browser extension to see faults highlighted on the page while they work.
• Public bodies and universities get an audit summary they can act on, with the worst pages first.

Example rules: lang attribute does not match the detected script of the text; Urdu text with no dir="rtl" on it or an ancestor; a Nastaliq font requested but not loaded, so the browser falls back to Naskh or a box glyph; an image whose surrounding content suggests it contains Urdu text and whose alt text is empty; form labels and their error messages in different languages; directional icons (arrows, chevrons) not mirrored in RTL layouts; numbers in mixed digits within a single field.

The technically interesting part

• Script and language detection at element level. A page can mix Urdu, English and Arabic in a single paragraph. You need Unicode block analysis plus a small character n-gram model to tell Urdu from Arabic and Persian, since they share most letters.
• Rendering checks. Use Playwright to read computed styles and the fonts actually used for each text node, so you can catch a silent fallback from Nastaliq to another font.
• Image text heuristics. Without heavy AI, combine image dimensions, file names, nearby headings and empty alt text to flag likely text images, and measure your false positive rate honestly. Optional OCR can confirm suspicious images.
• Screen reader ground truth. For every rule, record what NVDA or TalkBack actually says on a failing and a passing test page. This turns opinions into evidence.

How to evaluate it

• Precision and recall of each rule on a hand-labelled set of at least 200 elements from real pages.
• Coverage: how many faults in your audit were missed by axe-core alone.
• Screen reader impact: for a sample of faults, show the before and after output from the screen reader once the fault is fixed.
• Usability: ask three or four developers to fix a test page using only your report and time them.

Suggested plan

• Weeks 1 to 3: read the W3C Urdu documents and WCAG language rules; build ten failing test pages; test them with a screen reader.
• Weeks 4 to 7: script detection, direction and font rules as axe-core custom rules.
• Weeks 8 to 10: crawler, reports and browser extension.
• Weeks 11 to 13: audit of real sites, precision and recall measurement.
• Weeks 14 to 15: report, write-up and demo.

Path to a product

Public bodies are under growing pressure to make services accessible, and agencies that build sites for them need a checker. The rule set can be offered as an open source axe-core plugin, with paid audits or a hosted dashboard for agencies. It also makes a strong portfolio piece for frontend and accessibility roles, which are rare skills in the local market.

Scope warning

Do not try to build a full accessibility checker; extend axe-core with Urdu rules. Keep OCR optional. When publishing the audit, report patterns and anonymised counts rather than shaming named organisations, and contact any site with serious faults privately first.

Learn what you need on Sefism

• Frontend development roadmap: HTML semantics, CSS and the browser rendering basics behind these checks.
• axe-core: the engine you extend with custom rules.
• WCAG Quick Reference: the success criteria for language of page and parts.
• Learn Accessibility on web.dev: screen readers, focus order and ARIA.
• Playwright Documentation: crawling pages and reading computed styles.

Get help with this idea

The hard parts are telling Urdu from Arabic and Persian reliably and proving each rule matters to real screen reader users. Tauseef can help you pick the first rules, plan the screen reader tests and keep the audit fair. 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