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.

Page and passage direction are identified technically, and numbers, email addresses, filenames, and English text within Arabic are reviewed. Right alignment alone is insufficient where reading order, navigation, or screen-reader pronunciation is incorrect.

Required fields are identified by the word “required,” a technically defined symbol, and instructions at the start of the form. Color or an unexplained asterisk is not the only indicator, and a label does not disappear when typing begins.

• Identify the field and problem.
• Explain the expected format with an example.
• Move focus or provide a navigable error summary.
• Preserve valid information already entered.
• Do not use only “an error occurred” where detail is available.

• Use heading styles rather than visual formatting alone.
• Set correct language and direction.
• Provide alternative text for images and charts.
• Use tables with clear headers.
• Use descriptive links.
• Run accessibility checks before publication.

• Use clear worksheet names.
• Begin tables in a known location with headers.
• Avoid blank cells for layout and unnecessary complex merging.
• Explain symbols, units, and missing values.
• Do not rely on color alone.
• Provide CSV or a Web table where appropriate.

• Use a unique title for each slide.
• Set logical reading order.
• Use readable contrast and type.
• Provide meaningful alternative text.
• Explain charts and tables.
• Provide notes or a text version where slides alone do not carry meaning.

Review structural tags, headings, reading order, language, selectable text, alternative text, tables, links, and bookmarks. Where a complex PDF cannot be remediated, provide HTML, Word, or another alternative on request.

Video provides captions and, where needed, description of important visual information; audio provides a transcript. Player controls work by keyboard, playback and volume can be controlled, and audio does not start automatically.

Device reduced-motion preferences are respected where possible, and unnecessary rotating graphics or transitions are stopped. Harmful flashing is prohibited, and countdowns or motion are not used to force a decision.

• Announce opening to assistive technology.
• Move focus into the dialogue and return it after closing.
• Allow keyboard closure.
• Provide a clear title and named close button.
• Do not repeatedly or unjustifiably block an essential service.

Search and filters are labeled, selection state and result count are visible, and a no-results message is provided. Filters can be cleared and results reached by keyboard; operation does not depend on dragging or an unnamed icon.

A map provides an alternative list, table, or text search. Area information does not require precise clicking, contrast and zoom are reviewed, and the map is not the only route to an address or result.

Legacy remediation is prioritized by use, importance, connection to a right or service, user request, and feasibility. An accurate notice and alternative are provided, and untested legacy files are not described as accessible.

• Request documented keyboard and screen-reader support.
• Test Arabic and direction rather than relying only on a vendor statement.
• Require remediation and updates.
• Require data export or an alternative route.
• Include accessibility in acceptance rather than treating it as an optional extra.

• Heading structure and clear language.
• Appropriate alternative text.
• Descriptive links.
• Noncomplex tables.
• Review of files and charts.
• Display file type, size, and language.

• Define indicators and analytical bases.
• Provide data or table alternatives to charts.
• Avoid overcrowded color and category design.
• Provide a summary of pattern and limitations.
• Test dashboards and downloads.
• Provide a format for people unable to use interaction.

Training covers content, documents, charts, forms, keyboard and screen-reader testing, Arabic support, alternative-format requests, and vendor assessment. It is repeated when templates or systems change.

Where a problem is not resolved, a user may request review, use the complaint channel, or request an urgent temporary solution. An external competent body will be added after jurisdiction is determined, and a user need not disclose a diagnosis to exercise access rights.

• Plain text, HTML, or Word copy.
• Alternative table for a dashboard or chart.
• Assistance completing a form.
• Transcript or audio description.
• Smaller file or direct link.
• Information read or provided through another appropriate channel.