Accessibility

The site uses the WCAG 2.2 recommendations published by W3C as guidance, but it does not claim an independent formal AA or other conformance certification. Automated tools and browser tests can identify important failures, but they do not replace real use by disabled people.

Accessibility is not a one-time gate. Every new page, quiz, table, gallery or menu behaviour should be retested for keyboard use, focus, zoom, screen size and content structure.

• Every page provides a skip link to the main content.
• One H1 per page and meaningful H2/H3 order are targeted.
• Links and buttons use real semantic HTML elements.
• Focus indicators remain visible.
• Dropdown menus support keyboard sequence and Escape.
• After a modal or gallery closes, focus should return to the opening control.

Light and dark themes preserve the same content hierarchy. Colour is not the only signal for correct, incorrect, active or complete states; text, badges or shape provide another cue. Long headings, enlarged text and 125% zoom should work without clipping.

Non-essential motion is reduced when the user requests reduced motion. Reading should not require tracking animation. Decorative images are hidden from assistive technology, while informative images receive functional alternative text.

• 360, 390, 430, 768, 1024, 1280, 1440 and 1920 pixel layouts
• 125% zoom and long headings
• Completing primary tasks by keyboard only
• Closing menus and dialogs with Escape
• Visible focus and logical order
• Light and dark themes
• Horizontal overflow and table scrolling
• Single H1, alt text and language metadata
• Quiz feedback and error messages
• Reduced-motion preference

Browser, screen reader, operating system, magnification and input combinations are numerous. The site does not claim that every combination has been manually tested. PDFs, video, audio or future third-party components would introduce further requirements.

The site has no public contact form. This supports data minimisation, but it also means accessibility feedback cannot be submitted through an on-site form. External owner-managed channels would need separate handling.

Accessibility evaluation should not stop after counting elements on a page. A user should be able to reach a lesson through navigation, complete a quiz, read an explanation after an error, delete progress data and open and close the gallery. Testing is incomplete until a real task can be finished.

Keyboard review needs focus context as well as Tab order. When a mega menu opens, users should know where they are; when a mobile menu closes, hidden links should not receive focus; when a dialog closes, focus should not disappear. Magnification must preserve task order, not merely make content visible.

Human testing covers both language versions. Longer English text can cause buttons, headings or navigation to overflow. Passing the Turkish page does not automatically pass its counterpart.

• Reach target content through navigation
• Complete quiz and feedback task
• Delete stored data
• Use gallery dialog and focus return
• Check TR/EN length and overflow differences

Accessibility is not only a CSS or JavaScript task. An unclear link label, very long paragraph, unexplained abbreviation, incorrect heading order or colour-only table can remain a barrier even where the technical shell is correct.

A content author should match the heading to the real question, make link destinations understandable, build table headers correctly and decide why an image is present. Clarity of terms on English pages also requires human review.

• Match headings to questions
• Use meaningful link text
• Build correct table headers
• Write functional image descriptions
• Review English terminology