Accessibility
How FindEdition approaches accessible design and content — and how to tell us when something blocks you from using findedition.com.
Last updated: July 25, 2026 About 8 min read
At a glance
FindEdition aims to make findedition.com usable for as many people as possible, including people who rely on keyboards, screen readers, magnification, or captions. We follow recognized accessibility practices in our design and publishing workflows. We do not claim WCAG certification or any formal accredited audit seal on this page.
- Semantic HTML, headings, and landmarks help assistive technologies.
- Keyboard access and visible focus are design priorities.
- Informative images should have appropriate alternative text.
- Send accessibility feedback via the contact form or [email protected].
Overview
FindEdition is a large, multi-section site: news and publishing, entertainment discovery, mobiles and autos, recipes, tools, jobs, and community features. Accessibility work is therefore ongoing — not a one-time checklist we can pretend is finished forever.
This statement describes our approach, the practices we aim for, known categories of limitation (especially third-party embeds and ads), and how to report barriers. It complements our Content Standards and Privacy Policy.
We avoid over-claiming. Saying we “aim for recognized practices” is intentional. Certification language would imply a formal conformity assessment we are not asserting here.
Our Approach
Accessibility is part of product quality. When we ship new templates — policy pages like this one, catalog cards, forms, or tools — we try to reuse patterns that already work with assistive technology: labeled controls, sensible heading order, skip-friendly structure, and contrast that remains readable in light UI themes used across the site.
Editorial contributors are encouraged to write descriptive link text, avoid “click here,” and provide alt text for informative images. Decorative images should be marked so they can be ignored by screen readers when templates support that distinction.
Feedback from people who actually use assistive technology is especially valuable. We prioritize concrete reports (URL, what you tried, what failed, browser and AT if known) over vague complaints.
Practices We Aim For
Semantic structure
Use headings, lists, tables for tabular data, and landmarks (such as main) so pages make sense when CSS is limited.
Keyboard operability
Interactive controls should be reachable and usable without a mouse where we control the component.
Contrast & text
Body text and key UI should maintain readable contrast; avoid relying on color alone for meaning.
Forms & errors
Labels, instructions, and error messages should be associated with fields so mistakes are understandable.
Alternative text
Informative images need text alternatives; complex charts should have a textual summary nearby when feasible.
Motion sensitivity
We aim to avoid essential information that exists only in rapid flashing or unstoppable motion.
These aims guide internal review. They are not a certificate, score, or warranty that every historical page already meets every success criterion of any particular standard version.
Keyboard Navigation & Focus
Many FindEdition interfaces — including documentation-style policy pages with a table of contents — are designed to work with keyboard navigation. Focus styles should remain visible. Mobile menu toggles and overlays should be operable and dismissible without pointer-only traps where we control the script.
If you encounter a keyboard trap (focus stuck inside a modal or menu), please report the page URL and the control that trapped focus. Those bugs are high priority because they block core access.
Visual Design & Contrast
Policy and article layouts generally use dark text on light surfaces for long reading. Status colors (success, warning, error) should pair icons or text with color. Users can also employ browser zoom and operating-system contrast settings; we try not to break reflow at common zoom levels on modern browsers.
Some entertainment or marketing modules use richer visuals. When contrast is insufficient, tell us which component failed — hero, card, badge, or chart — so we can target a fix.
Images, Video & Media
Catalog images (posters, devices, dishes) should include meaningful alt text when they convey information beyond decoration. User-uploaded images may vary in quality; we encourage contributors to add descriptions and may improve templates over time.
FindEdition does not operate as a movie streaming host. Embedded third-party trailers or players, when present, inherit the accessibility features of those providers. Captions and audio description availability depend on the source.
Icons used for navigation should include accessible names (for example, aria-label on icon-only buttons), as used on this policy layout’s menu controls.
Content Structure & Language
Long pages should use a single H1 and ordered H2/H3 sections with id anchors — the pattern used by FindEdition policy documents — so readers can jump via the table of contents or assistive technology rotor. Plain language helps everyone, including people with cognitive disabilities.
Recipes should keep ingredients and steps readable as lists. Data-heavy mobiles and autos pages should expose key specs as text, not only in images. Jobs listings should not bury critical application instructions inside inaccessible graphics.
Third-Party Content & Ads
When advertising services are enabled, third-party creatives and iframes may introduce barriers we do not fully control. Consent interfaces should themselves remain operable; if our CMP experience blocks keyboard or screen reader use, report it immediately.
Community posts, affiliate modules (when enabled), and embedded widgets can also vary. We still want reports: even when a fix requires partner changes, we can often adjust how FindEdition loads or labels the embed.
See the Advertising Policy for commercial context and the Disclaimer for general third-party limits.
How to Send Accessibility Feedback
Please tell us about barriers using one of these channels:
- Contact form — choose Feedback, Support, or Technical Issue as appropriate.
- Email [email protected] with subject line “Accessibility”.
- For content wording that is especially hard to parse on a staff article, you may also copy [email protected].
Helpful details include: the page URL, what you were trying to do, what happened instead, device/browser, and assistive technology if relevant. We aim to acknowledge actionable reports and fix confirmed issues as capacity allows. We do not guarantee a specific SLA on this statement.
Legal accessibility correspondence can be directed to [email protected].
Ongoing Improvement
We expect to keep improving templates, form patterns, media components, and documentation-style pages like this one. Entertainment catalogs, comparison tools, and marketplace flows are iterative products; accessibility regressions can appear when new UI ships, and we treat those as defects to triage.
If a correction to alt text or heading structure is needed on a published page, our Corrections Policy channels can also carry that report.
Thank you for helping FindEdition make FindEdition more usable. Accessibility is shared work between engineering, design, editorial, and the people who rely on these features every day.
Related policies
Published by FindEdition on findedition.com. Read the companion policies for full context.