AccessBridge

Accessibility and inclusion criteria

Version 0.1, draft | LAMP Consultancy | 29 August 2026 Status: for internal review, not yet agreed with any coordinating partner

This is the acceptance criteria sheet. Nothing ships unless it passes everything marked Must. Give this document to whoever builds the product, whether that is a developer, an agency or an AI builder.

1. Standards adopted

Layer	Standard	Why
Interface	WCAG 2.2 Level AA	Current W3C recommendation. Above Ontario's AODA floor, which still references WCAG 2.0 AA
Documents and exports	EN 301 549	Covers exported situation reports and PDFs, which WCAG alone does not
Programme design	IASC Guidelines on Inclusion of Persons with Disabilities in Humanitarian Action, 2019	The inclusion standard the UN and Red Cross system recognises
Quality and accountability	Core Humanitarian Standard 2024, within the Sphere frame	Nine commitments to people affected by crises
Languages	English and Nepali only	See section 6

Claim these accurately. Say "built to" until it has been independently tested, then "conforms to". Do not claim IASC alignment until a disabled people's organisation has reviewed the product.

2. What IASC 2019 requires of this product

The guidelines set four must-do actions. Each one has a product consequence.

1. Promote meaningful participation. Persons with disabilities and their representative organisations take part in design, not just testing at the end.

Must: at least one Nepali disabled people's organisation reviews the interface before public launch, and the review findings are recorded
Must: the review outcome is named in the accessibility statement, including anything not yet fixed

2. Remove barriers. Attitudinal, environmental and institutional. In a dashboard these show up as:

Must: no need record may bury accessibility in free text. Accessibility need is a structured, filterable field
Must: the interface itself meets section 5 in full, so a disabled coordinator can use the tool
Must: no feature requires a fast connection, a recent phone or a data plan to read the public board

3. Empower and build capacity. Local actors update records themselves rather than depending on you.

Must: verified local partners can submit and update entries directly, in Nepali
Should: a written handover route exists so the board can be run without LAMP

4. Disaggregate data by sex, age and disability. This is the one that changes your data model. See section 3.

3. Use the Washington Group Short Set, not your own filter list

Your plan lists useful accessibility filters, but they are invented categories. Swap them for the Washington Group Short Set, which is the humanitarian standard for disability disaggregation and is what IFRC, UNHCR and OCHA already use. Your data then interoperates with theirs instead of sitting in a silo. This single change is the strongest credibility move in the whole build.

Six functional domains, each asking about difficulty:

Seeing, even if wearing glasses
Hearing, even if using a hearing aid
Walking or climbing steps
Remembering or concentrating
Self care, such as washing all over or dressing
Communicating, understanding or being understood

Four response options: no difficulty | some difficulty | a lot of difficulty | cannot do at all. The recognised threshold is "a lot of difficulty" or "cannot do at all" in at least one domain.

Rules for AccessBridge:

Must: aggregate only. Never collect or display these at individual level on any public surface
Must: report as counts or ranges at district or municipality level
Must not: use the Short Set as an intake screener for individuals. It is a population measure, not an eligibility test
Should: keep your operational filters as a separate layer sitting on top, since they describe what the response must provide rather than who someone is: accessible transport required, cold chain required, power-dependent equipment, mobility aid replacement, accessible shelter unavailable, interpretation required, caregiver support required

4. Which CHS 2024 commitments bind this product

Of the nine, four are directly product-shaping.

Commitment	What it means here
People can exercise their rights and participate in decisions that affect them	Section 2 above, plus plain-language public content in both languages
Access support that does not cause harm to people or the environment	Section 7. The harm risk in this product is publishing location or personal information, or publishing something false with an authoritative face
People can safely report concerns and complaints and get them addressed	Must: a working feedback route on every page, in both languages, that reaches a named human, with a stated response time
Access coordinated and complementary support	Must: the board states what it does not cover, and links to the official coordination sources rather than competing with them

5. WCAG 2.2 AA criteria, by component

All Must unless marked otherwise.

Everything

Contrast: 4.5:1 for body text, 3:1 for large text, and 3:1 for interface components, icons and chart elements
Every interactive element reachable and operable by keyboard alone, in a sensible order, with no traps
Focus indicator clearly visible and never hidden behind sticky headers or banners
Touch targets at least 24 by 24 CSS pixels, with spacing if smaller
Usable at 320px width and at 400% zoom without horizontal scrolling or lost content
Respects reduced-motion settings. No auto-refresh that moves content under someone reading it
Page has a proper heading structure, one h1, no skipped levels
Every page has a descriptive, unique title

Severity and priority indicators

This is your highest-risk component, because your whole board is severity coded.

Must not convey severity by colour alone. Every severity carries a text label and a distinct shape or icon
Must pass contrast at 3:1 against its background for the indicator itself
Must read correctly to a screen reader as words, for example "Critical", not as a colour name or an empty span

Data tables (Sections A to D of the board)

Real table markup with row and column headers correctly associated. No layout done with divs pretending to be tables
Each table has a caption saying what it contains and when it was last reviewed
On narrow screens the table reflows or becomes a card list. It must not require horizontal scrolling of the whole page
If the table scrolls within its own container, that container is keyboard focusable and labelled
Sorting and filtering are operable by keyboard, and the result count is announced

Filters and search

Every control has a visible label, not a placeholder standing in for one
Applied filters are shown as removable items, each individually clearable
Results update is announced to assistive technology via a live region
No drag-only interaction anywhere. Anything draggable has a click or keyboard equivalent

Maps

The map is never the only way to reach information. An equivalent list or table view carries the same content
Map is not required for any core task
District-level only, per section 7

Forms (partner intake)

Errors identified in text, tied to the field, and describing how to fix it
No information the user already gave is asked for again in the same process
No authentication step that depends on remembering, transcribing or solving a puzzle. Copy and paste into fields must work
Required fields marked in text, not by colour or an unlabelled asterisk alone
Consent and visibility choice is an explicit, unticked control with plain-language explanation

Exported situation reports

Tagged, structured PDFs with reading order, headings, table headers, language set and a document title
Or offer the export as accessible HTML or CSV as well, which is simpler and usually better
Never export an image of a table

Timestamps

Every record shows source, verification status, last reviewed date and next review date, in text
Times shown in Nepal Time, UTC+5:45, and labelled as such
Should: offer Bikram Sambat alongside Gregorian dates in the Nepali interface, since that is the civil calendar in Nepal

6. Language

English and Nepali. Two languages, nothing else, for this release.

Human translation only. No machine translation of any safety-relevant content
Language switch on every page, visible without scrolling, labelled in its own language: English / नेपाली
Choice persists across pages
Correct lang attributes on the page and on any mixed-language content, so screen readers pronounce Nepali correctly
Devanagari renders in a font that supports it fully, tested on Android, which is what most users will have
Plain language target: grade 7 to 9 reading level in both languages
Do not translate an organisation's official name or its donation URL
If a record exists in English only, label it as untranslated rather than hiding it or auto-translating it

Anything beyond these two languages waits for a partner who can verify and maintain it. Tamang is the majority language in Rasuwa and matters enormously for community-facing content, but community-facing content is not what this release is.

6a. Audio

Yes, and it should. Literacy in Rasuwa is around 70%, so roughly three in ten adults cannot read either of your two languages. Text alone excludes them.

Be clear which need audio is solving. Screen readers already read the whole interface aloud for blind users, and that is handled by section 5. Audio here is a different thing: spoken content for people who cannot read, which no screen reader helps with, because a screen reader user still has to operate a screen reader.

What gets audio. Only the stable content. Do not attempt spoken versions of the live board, which changes hourly and would be stale or wrong within a day.

Must: the "what you can do today" guidance, in English and Nepali
Must: the safe-donation message, including "do not self-deploy and do not send unsolicited goods"
Must: what this board is, who runs it, and what it does not do
Must: how to report a concern or complaint
Should: a short daily spoken summary, if and only if a named person records it and it carries the same timestamp discipline as everything else

How it must behave.

Must not autoplay. Nothing plays without the user starting it
Must have visible play, pause and stop controls, keyboard operable, with a target of at least 24 by 24 pixels
Must have a full text transcript on the same page. The audio is an addition to the text, never a replacement
Must be labelled with its language and duration before play, for example "Listen in Nepali, 1 min 40 sec"
Must use a clear speaking voice, unhurried, no background music
Should be under 2 minutes per clip and under 1MB, since your users are on slow connections and may be paying for data
Should be downloadable, so someone can save it and share it offline

Recording it. Human voice, not text to speech. Nepali text-to-speech quality is poor and mispronunciation of place names in a disaster context is not a cosmetic problem. Record once, by a native speaker, for content that will not change. If you cannot record Nepali audio to a decent standard yet, ship English audio and label the Nepali version as coming, rather than shipping a synthetic voice.

Do not put audio behind autoplay, a carousel, a modal, or anything that starts on scroll.

7. Do no harm rules, non-negotiable

District or municipality level locations only. No coordinates, no addresses, no facility pinpoints
No personal data of any affected person, anywhere, in any field, including free text
No missing-person information, sightings or family tracing content
No live positions or movements of rescue teams, convoys or stock
Restricted operational detail is partner-only and access controlled, never a hidden field on a public page
Every public entry carries source, verification status, owner, timestamp and expiry
Unverified entries are never publicly visible. Not greyed out, not flagged, not visible
Free-text fields are reviewed by a human before any public display

8. Testing and evidence

Automated tools find roughly a third of accessibility problems. They are the start, not the test.

Automated scan on every page, zero critical issues
Full keyboard-only pass by a human, every task completed without a mouse
Screen reader pass: NVDA on Windows and VoiceOver on iOS, minimum
320px and 400% zoom pass
Throttled slow connection pass on a low-end Android device
Audio pass: nothing autoplays, every clip is keyboard operable, every clip has a matching transcript
Session with at least two disabled users, including one screen reader user and one Nepali speaker
Publish an accessibility statement naming the standard, the date tested, known failures and a contact route

Record the results. If you cannot yet do item 7, say so publicly rather than implying you have.

9. Honest position on where this stands

Nothing here has been agreed with a coordinating body. Until Nepal Red Cross, NDRRMA or an OCHA-linked partner confirms they will verify entries, sections A to C of the board should not be public. The verified donation directory can be, because its facts come from organisations' own domains and can be rechecked without field access.

Build the directory to this standard first. It is small enough to get completely right, and a small thing done properly is a better introduction to a coordinating agency than a large thing done partly.