Digital Accessibility Statement

The Center seeks to make pages, forms, files, and data usable by persons with disabilities, assistive-technology users, and people facing device, connectivity, or language barriers. No defined conformance level is claimed before the operational Website is tested.

• Navigate, read, and understand content.
• Use a keyboard and screen reader.
• Complete forms and understand errors.
• Read tables and charts or obtain alternatives.
• Download files and access audio and video.
• Use mobile devices and low-bandwidth connections.
• Request alternative formats or complain.

• Blind and low-vision users.
• Deaf and hard-of-hearing users.
• People with motor disabilities.
• Screen-reader and keyboard users.
• People with reading, cognitive, or learning difficulties.
• Users sensitive to motion or flashing.
• Older people and users of small, old, or low-bandwidth devices.

Development is informed by recognized accessibility practice and the Web Content Accessibility Guidelines. The Website should not be described as fully conformant, certified, or barrier-free before documented testing.

• Correct heading hierarchy.
• Clear paragraphs and lists.
• Descriptive links.
• Instructions not based solely on visual position.
• Definitions and summaries.
• Technically identified page and passage languages.
• Right-to-left Arabic and left-to-right English, including mixed text.

Links, menus, buttons, fields, search, dialogues, and core functions should be reachable without a mouse. Focus order is logical, focus is visible, and users are not trapped.

• Structured headings and page regions.
• Labels linked to fields.
• Clear button names and expanded states.
• Readable errors.
• Defined table headers.
• Appropriate image and chart descriptions.
• No visually functional but semantically meaningless controls.

Informative images describe essential meaning, decorative images are hidden, logos identify organizations, charts receive descriptions or tables, and text within images is available as real text where possible.

• Do not rely on color alone.
• Provide title, axes, legend, source, and date.
• Summarize key results and offer alternative data tables.
• Define row and column headers and logical order.
• Explain abbreviations and avoid unnecessary merged cells.
• Provide simplified, downloadable, or divided versions of large tables.

Design seeks sufficient contrast, identifiable links and focus, and errors not communicated by color alone. Content remains usable when text or page zoom changes, fonts are enlarged, screens rotate, or small displays are used.

Link text describes destination, such as “Download the dataset,” rather than “click here.” Buttons are named, keyboard- and touch-usable, adequately spaced, and not dependent on an unexplained icon or hover alone.

• Clear title and concise instructions.
• Visible label for every field.
• Required fields identified by text or a defined symbol.
• Expected input format.
• Error identifying location and correction.
• Submission confirmation and review of important information.
• Labels that do not disappear when typing.

Unnecessary time limits are avoided. Session expiry should warn users and allow extension or progress preservation where feasible. Bot protection should not depend only on images and should provide accessible alternatives and language support.

PDF review covers reading order, headings, selectable text, language, tags, tables, links, and contrast. Word, Excel, and PowerPoint use headings, alternative text, accessible tables, reading order, and language. HTML or alternatives are preferred for complex files.

• File type, size, language, and format.
• Expected software.
• Whether compressed.
• Alternative formats.
• Basic instructions.
• Open or commonly supported formats where practical.

Media should provide captions, transcripts, descriptions of important nonverbal information, keyboard controls, volume, and no automatic sound. Visually dependent video may require audio description or text equivalent.

Rapid flashing, continuous motion, and autoplay are avoided and reduced-motion settings respected. Dialogues have titles, are announced, close by keyboard, return focus appropriately, and do not block core content without justification.

• Clear label.
• Keyboard operation.
• Useful no-results message.
• Filter reset.
• Result count.
• Accessible names for icons.

• Keyboard navigation and named filters.
• Announced selection state and updates.
• Alternative tables and chart descriptions.
• Data downloads.
• No drag-only controls.
• Small-cell warnings.
• Static or report-based alternatives where full accessibility is not possible.

Maps should provide purpose descriptions, alternative lists or tables, text information by area, nonmap search, clear controls, and notice of external providers.

Technical material may require plain-language summaries, definitions, indicator explanations, reading examples, limitations, and concise versions. Accessibility organizes precision for different users rather than removing it.

• Avoid unnecessary horizontal scrolling.
• Usable menus, buttons, and fields.
• Compressed images and no autoplay.
• Reduced unnecessary components.
• Display file sizes and provide text pages.
• Do not require download to understand core information.

Video, maps, forms, meetings, and older files may be less accessible. The Center seeks suitable providers, identifies external services, offers alternatives where possible, and prioritizes legacy remediation by importance, demand, and feasibility.

Platforms are assessed for keyboard, screen reader, contrast, Arabic, forms, generated documents, and vendor remediation—not only price and functions. Developers own structure and testing; editors own headings, alternative text, and links; researchers own accessible visuals, tables, and definitions.

• Automated testing.
• Keyboard and screen-reader testing.
• Zoom, mobile, and contrast review.
• Forms and both languages.
• Documents and charts.
• Testing with users who have different needs.
• Retesting after changes and complaints.

After testing, the Statement should list actual unresolved issues, affected content, alternatives, and remediation plans. Limitations should not be invented before operational review.

Users may request plain text, HTML, Word, spreadsheet, high contrast, transcript, chart description, dashboard table, or plain-language versions without providing a medical diagnosis.

Request accessibility support or an alternative format

1. Confirm receipt.
2. Identify the page or function.
3. Assess impact and priority.
4. Provide a temporary solution or alternative.
5. Refer for technical or editorial action.
6. Test correction.
7. Inform user and document the issue.

Priority is given to barriers preventing complaints, privacy requests, essential information, or causing health risk. Detailed health information is not required; submitted information is used to understand and address the barrier.