Accessibility & Internationalization Requirements

Accessibility & Internationalization Requirements

A prototype that only works for able-bodied, English-speaking users on a desktop browser is incomplete — regardless of how polished it looks. Two categories of requirements that analysts frequently under-specify are accessibility (a11y) — ensuring the system is usable by people with disabilities — and internationalization (i18n) — designing the system so it can be adapted to different languages, cultures, and regions without re-engineering. Both must be gathered, documented, and validated alongside every other functional requirement.

Why Analysts Own These Requirements

Accessibility and i18n failures are expensive to retrofit. A government clinic booking system discovered — after six months of development — that its date-picker widget was entirely keyboard-inaccessible, blocking registrants who rely on screen readers. Fixing it required reworking the component library, re-testing every form, and delaying go-live by eight weeks. The analyst who wrote the requirements had treated accessibility as a "nice-to-have" note rather than a testable requirement. That is the failure pattern this lesson prevents.

Accessibility Fundamentals for Analysts

The primary international standard is WCAG 2.2 (Web Content Accessibility Guidelines), organised around four principles: Perceivable, Operable, Understandable, Robust — remembered as POUR. Each principle contains success criteria at levels A (minimum), AA (standard compliance target for most commercial and government systems), and AAA (enhanced).

• Perceivable: All non-text content has a text alternative (alt text on images, captions on video). Colour alone is never the sole means of conveying information. Minimum contrast ratio is 4.5:1 for normal text (WCAG AA).
• Operable: All functionality is reachable via keyboard alone. No interaction requires more than a single pointer gesture without a keyboard alternative. Session timeouts warn users and allow extension.
• Understandable: Form fields have visible labels (not just placeholder text). Error messages identify the field, describe the problem, and suggest a correction. Language of the page is declared in markup.
• Robust: Markup is valid and parseable by assistive technologies. ARIA roles and live regions are used correctly — not as decoration.

As an analyst your job is to translate these principles into testable acceptance criteria. "The system shall be accessible" is not a requirement. "All form input fields shall have programmatically associated labels; this shall be verified by automated axe scan scoring zero critical violations" is a requirement.

Internationalization (i18n) Requirements

Internationalization is the architectural decision made before a single line of production code is written. If the system is not designed for i18n from the start, adding Arabic, French, or Japanese later means refactoring database schemas, string extraction, layout engines, and date/currency formatters — not just translating text. As an analyst, you must surface these needs in the requirements phase.

Key i18n dimensions to specify:

• Text direction: Arabic, Hebrew, Persian, and Urdu are right-to-left (RTL). A logistics platform expanding to Gulf markets must specify: "The interface shall fully support RTL layout. All directional CSS properties shall use logical values (start/end) rather than physical values (left/right). Page mirroring shall be verified on Chrome and Firefox."
• Date and time formats: The same moment in time renders as 06/10/2026 in the US, 10/06/2026 in the UK, and 10 يونيو 2026 in Arabic — or uses the Hijri calendar in some contexts. Specify the locale-aware formatting library and which calendar system(s) the system must support.
• Number and currency formats: 1,234.56 (US) vs 1.234,56 (Germany) vs ١٢٣٤٫٥٦ (Arabic-Indic numerals). Multi-currency systems must specify precision, rounding rules, and symbol placement.
• String externalisation: All user-facing text (labels, error messages, tooltips, email templates) must be stored in resource files, never hard-coded. Specify the key-value format (JSON, YAML, PHP arrays) and the translation workflow.
• Text expansion: German and Arabic translations of English strings are typically 30–40% longer. Layouts must accommodate expansion without breaking. Specify minimum/maximum character budgets for constrained UI elements such as navigation labels and button text.
• Sorting and collation: Alphabetical sorting in Arabic does not follow Unicode code-point order. A system displaying a sorted list of Arabic product names must use locale-aware collation.

RTL Layout: What Changes and What to Specify

For a system that must support Arabic or Hebrew, the analyst must document the following in the UI requirements specification:

• The entire layout mirrors horizontally: the primary navigation moves from the left to the right, breadcrumbs and reading order reverse, and icons with directional meaning (arrows, progress indicators) flip.
• Form fields remain left-aligned when the user types Latin characters (auto-detected by browser), but labels and the surrounding layout remain RTL.
• Tables: column headers and row data flow right-to-left. Numeric columns (prices, quantities) can remain LTR inside an RTL table.
• Image placement: a hero image with a person "looking toward content" should be mirrored so the subject looks right (toward the content) in LTR and left in RTL.

Documenting Accessibility and i18n Requirements

These requirements belong in the Non-Functional Requirements (NFR) section of the Software Requirements Specification (SRS) or as a dedicated Accessibility & Internationalization Requirements sub-section. Use the same SHALL / SHOULD / MAY language and ensure each requirement is testable.

Gathering These Requirements from Stakeholders

Stakeholders rarely volunteer accessibility and i18n needs. Analysts must ask directly:

• "Are any of your users likely to be using assistive technology — screen readers, voice control, switch access?"
• "Does your organisation have a legal or regulatory obligation to meet WCAG AA?" (Government agencies in the EU, UK, and US often do.)
• "Which countries or language markets will this system serve now, and in the next two years?"
• "Are any target markets primarily RTL-language speakers?"
• "Who will manage translations — an internal team, a translation agency, or a community?"

Validating a11y and i18n in Prototypes

Even a high-fidelity HTML prototype can be partially evaluated against accessibility and i18n requirements before development begins:

• Run axe DevTools or Lighthouse accessibility audit on the clickable prototype to catch missing labels, contrast failures, and missing landmarks.
• Apply a browser extension (e.g., NoCoffee Vision Simulator) to simulate low vision, colour blindness, and blurred vision on the prototype screens.
• Test the prototype with a screen reader (NVDA + Firefox on Windows, VoiceOver + Safari on macOS) — navigate through the key flow with eyes closed.
• For i18n, switch the prototype to the longest translation and confirm no overflow or truncation. For RTL, apply dir="rtl" to the prototype root and inspect the layout.

Document your findings as prototype evaluation issues with severity (critical, major, minor) and the WCAG criterion or i18n requirement violated. This becomes input to the sprint backlog before a single line of production code is written.