Independent resource on real-time embedded systems · FRESCOR project archive 2006–2009

Accessibility Statement

On this page

    FRESCOR.org wants frescor.org to be usable by as many people as possible, including people who use screen readers, keyboard navigation, magnification, voice control or other assistive technologies. This Accessibility Statement explains the standard we aim for, what we have done to meet it, where we know we fall short, and how to tell us about problems.

    Last updated: October 19, 2026

    Key takeaways

    • We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA.
    • The site uses semantic HTML, skip links, full keyboard support, visible focus indicators, reduced-motion support and a dark mode.
    • Some archived PDF documents, third-party content and complex charts may not be fully accessible yet.
    • Please report any barrier to support@frescor.org. We aim to reply within five business days.

    Our commitment

    frescor.org is a knowledge resource about real-time embedded systems, and it preserves the archive of the original FRESCOR research project. Technical knowledge should be available to everyone, whatever their abilities and whatever device they use. We treat accessibility as part of the quality of the site, not as an afterthought. We consider it when we design templates, write articles, build interactive tools and choose third-party components.

    Conformance target

    We aim to meet WCAG 2.2 at Level AA. WCAG is published by the World Wide Web Consortium (W3C) and is the internationally recognized benchmark for web accessibility. It is also the basis of the European standard EN 301 549.

    Conformance status: partially conformant. This means most of the site meets the Level AA success criteria, but some content does not yet fully conform. The known gaps are listed under Known limitations.

    What we have done

    Structure and navigation

    • Semantic HTML. Pages use proper landmarks (header, navigation, main content, footer), a logical heading hierarchy, real lists and tables with header cells. This lets assistive technologies present the structure of each page.
    • Skip links. A “Skip to content” link is the first item on every page. It lets keyboard and screen reader users jump past the navigation. The original FRESCOR project website, launched in 2006, also offered accessibility skip links. We have kept that tradition in the redesigned site.
    • Table of contents. Longer articles and policies include an automatically generated table of contents, with links to each section.
    • Consistent navigation. Menus, search and footer links appear in the same place on every page. A site map lists every page.
    • Descriptive links. We write link text that makes sense out of context and avoid vague labels such as “click here”.

    Keyboard and focus

    • Keyboard navigation. All menus, buttons, form fields, FAQ items, the glossary filter and the schedulability calculator can be operated with a keyboard alone. The tab order follows the visual reading order.
    • Visible focus. Every interactive element shows a clear, high-contrast focus indicator. We do not remove the browser’s focus outline without providing an equal or better replacement.
    • No keyboard traps. Expandable sections, the mobile menu and the cookie banner can be closed with the keyboard, and focus returns to a sensible place.

    Visual design

    • Color contrast. Body text and interface elements are designed to meet the WCAG AA contrast ratios: at least 4.5:1 for normal text, 3:1 for large text and 3:1 for meaningful graphical elements and focus indicators.
    • Color is not the only cue. We aim to convey information such as errors, required fields, link states and calculator results with text or shape as well as color.
    • Dark mode. The site follows your operating system’s light or dark setting. You can also switch manually with the theme toggle. Your choice is remembered in your browser (see our Cookie Policy). Both color schemes are designed to meet the same contrast targets.
    • Resizable text and reflow. Text uses relative units. You can zoom to 200% without losing content or function. At 400% zoom (or at a 320-pixel-wide viewport), content reflows into a single column without horizontal scrolling, except for wide data tables and code samples, which scroll within their own containers.

    Motion

    • Reduced-motion support. The theme uses subtle animations, for example when content blocks appear. If you have turned on “reduce motion” in your operating system or browser (the prefers-reduced-motion setting), the theme disables these animations and transitions.
    • No flashing content. We do not publish content that flashes more than three times per second.

    Content

    • Alternative text. Informative images have text alternatives that describe their content or purpose. Purely decorative images are hidden from assistive technologies.
    • Plain language. We explain technical terms when we first use them, and expand abbreviations using the abbr element where helpful. Our glossary defines common real-time systems terms.
    • Formulas and code. Formulas are written as text rather than images, so they can be read by screen readers and enlarged without blurring. Code samples are presented as real text.
    • Page language. Every page declares its language (English), so screen readers use the correct pronunciation.

    Interactive widgets

    • Schedulability calculator. The calculator uses labeled form fields and ARIA attributes, so that inputs, validation messages and updated results are exposed to assistive technologies. Results are given as text and tables as well as in the Gantt chart.
    • Glossary filter. The filter on the glossary page has an accessible label, and ARIA is used so that changes to the list of matching terms can be conveyed to screen reader users.
    • Expandable content. FAQ items use native details and summary elements. The mobile menu and toggle buttons expose their state through aria-expanded and accessible names.

    Known limitations

    Despite our efforts, some content is not yet fully accessible. We are aware of the following issues:

    Area Issue What we are doing
    Archived PDF documents Some historical documents from the original FRESCOR project (2006–2009), such as deliverables and papers, were created before current accessibility practices. They may lack tags, a correct reading order or text alternatives for figures. Some may be scanned images. We are prioritizing the most frequently used documents for remediation. On request, we will try to provide an accessible version or a text summary.
    Charts and diagrams Some complex charts, timing diagrams and Gantt charts convey detailed information visually that is only partly described in text. We add text descriptions and data tables where practical. The calculator always provides its results as text.
    Third-party content External websites, embedded content and payment pages provided by third parties are outside our control and may not meet WCAG 2.2 AA. We consider accessibility when choosing providers, and we report issues to them when we find them.
    Older articles Some archived pages from the original project site may have less descriptive link text or incomplete heading structure. We correct these issues when we review archived pages. Original wording is preserved, but the markup is improved.

    How we assess accessibility

    This statement is based on a self-assessment by the team behind frescor.org. We have not commissioned an independent audit. Our approach combines:

    • Automated testing with common browser-based accessibility checkers, to catch issues such as missing labels, contrast failures and invalid ARIA.
    • Manual keyboard testing of templates and interactive features, checking tab order, focus visibility and the ability to operate every control.
    • Screen reader checks of key pages and widgets with widely used screen readers.
    • Zoom, reflow and display-setting checks, including 200% and 400% zoom, dark mode and reduced-motion settings.
    • Review of new content before publication, including headings, link text, alternative text and table structure, as part of our editorial process.

    Automated tools find only part of the possible accessibility issues. This is why we rely on manual checks and on feedback from people who use the site.

    Feedback and contact

    If you have difficulty using any part of frescor.org, or if you need information in a different format, please contact FRESCOR.org:

    To help us respond, please tell us the address (URL) of the page, what you were trying to do, the problem you met and, if you are happy to share it, the browser and assistive technology you use.

    Response time: we aim to acknowledge accessibility feedback within five business days. Where a fix is needed, we aim to resolve the issue, or to provide the content in an accessible alternative format, within 30 days. If a fix will take longer, we will explain why and tell you when you can expect it.

    Enforcement and legal framework

    The European Accessibility Act (Directive (EU) 2019/882) has applied since June 28, 2025. It sets accessibility requirements for certain products and services, including e-commerce services offered to consumers in the EU. Microenterprises that provide services are exempt. Whether or not the Act legally applies to us, we treat its requirements, and the WCAG 2.2 AA criteria referenced by EN 301 549, as our benchmark.

    If you contact us and are not satisfied with our response, you can contact the market surveillance or consumer protection authority responsible for accessibility in your EU Member State. Users in other countries may have similar rights under national law.

    Preparation of this statement

    This statement was prepared on October 19, 2026, based on a self-assessment of the redesigned site. We will review it at least once a year, and whenever we make significant changes to the site’s design, templates or interactive tools.

    ^ Top