Accessibility

Our approach

Accessibility is treated as part of product quality rather than a final visual adjustment. Public pages use semantic HTML, visible keyboard focus, readable text, descriptive links and layouts that adapt to smaller screens.

Mahlis reviews accessibility during development and responds to reported barriers according to their impact and available resources.

Website features

• A skip link provides direct access to the main content.
• Page regions use semantic header, navigation, main and footer elements.
• Heading levels communicate the structure of each page.
• Navigation and forms can be operated with a keyboard.
• Form fields have visible labels and associated error messages.
• Links describe their destination or purpose.
• Text can reflow when the browser is zoomed.
• Colour is not intended to be the only way information is communicated.
• Motion is avoided unless it serves a necessary purpose.
• Public articles use a focused reading width and consistent structure.

Navigation

The primary navigation contains Products, Roadmap, Articles and Contact. Product links are grouped in a menu that can be opened with a pointer or keyboard. Accessibility information remains in the footer so the primary navigation stays focused.

Keyboard focus must remain visible as a person moves through links, buttons, menus and form controls.

Text and reading layout

Heading sizes use responsive limits so long titles remain readable without overwhelming the page. Paragraph width and line spacing are constrained to support sustained reading.

Browser zoom should be used when larger text is needed. The layout is intended to adapt without requiring horizontal scrolling under normal responsive conditions.

Forms and messages

Contact and administrator forms use persistent labels rather than placeholders as the only instruction. Validation messages identify the field requiring attention and are exposed to assistive technology.

Session, security and submission messages should not rely on colour alone. Important messages use text and appropriate semantic roles.

Articles and uploaded content

Markdown articles pass through controlled validation and safe HTML rendering. Authors should use meaningful headings, descriptive link text, short paragraphs, lists where helpful and explanations for technical terms.

Images added in a future content release must include useful alternative text unless they are purely decorative.

Known limitations

Accessibility may vary across older browsers, browser extensions and assistive-technology combinations. External websites linked from Mahlis are outside our control.

Product prototypes may have separate accessibility limitations while they are being researched. A prototype page should describe those limitations and must not present unfinished research as an approved accessibility aid.

Report an accessibility barrier

If you encounter a barrier, use the Mahlis contact form and include:

• the page or feature you were using;
• what you expected to happen;
• what happened instead;
• your browser and assistive technology, if you are comfortable sharing them;
• an accessible way for Mahlis to respond.

Do not include passwords, patient records or other sensitive personal information in an accessibility report.

Review direction

Mahlis uses the Web Content Accessibility Guidelines as a reference for design and testing. A statement of conformance will be made only after the relevant pages and workflows have been assessed.