Add EAA blog post DRAFT

src/posts/2024-12-13-eaa.md

@@ -0,0 +1,107 @@
+---
+title: "European Accessibility Act"
+authorHandle: zeppelin
+tags: [process]
+bio: "Gabor Babicz, Senior Software Engineering Consultant"
+description: "What the European Accessibility Act means for you"
+og:
+  image: "data:image/png;base64,VBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAAtJREFUGFdjYAACAAAFAAGq1chRAAAAAElFTkSuQmCC="
+tagline: |
+  <p>
+    The European Accessibility Act (EAA) is a regulation that came into force on June 28, 2024. It requires that all websites and apps accessible to Europeans are accessible to people with disabilities. This is a big deal for all companies that develop software for the European market.
+  </p>
+---
+
+> TL;DR: The European Accessibility Act (EAA) is a directive of the European Union that aims to improve the trade between members of the EU for accessible products and services.
+>
+> After taking effect in April 2019, it will come in force on June 28, 2025. Failing to comply may result in fines costing from €5,000 to €20,000 **_per violation_**. For ongoing non-compliance, fines can be as high as €1,000 _per day._
+>
+> Mainmatter can help you with assessing and acting on EAA compliance, so your audience can use your services without obstacles, as mandated by the directive.
+
+## Introduction to the **European Accessibility Act**
+
+The **European Accessibility Act (EAA)** is a directive designed to ensure digital accessibility across the European Union, covering websites, mobile applications, software, and other digital and physical products used in sectors like e-commerce, finance, education, and transportation. By establishing unified accessibility standards, the EAA simplifies compliance for businesses operating in multiple regions, eliminating the need to navigate varying national regulations. This harmonization reduces compliance costs, expands market opportunities, and enhances digital experiences for people with disabilities and elderly individuals.
+
+Non-compliance with the EAA can lead to significant consequences, including fines and potential lawsuits. Businesses risk legal action, especially if their products or services are essential yet inaccessible. To mitigate these risks, organizations should prioritize accessibility by conducting regular audits, maintaining thorough reporting, and creating a knowledge base for customer support. By integrating accessibility into their strategy, businesses not only reduce liabilities but also foster a more inclusive user experience.
+
+### Compliance Timeline
+
+Product owners need to be aware of these key deadlines:
+
+- **June 28, 2025**: Deadline for most digital platforms (websites, mobile apps) and other covered products to comply with EAA accessibility standards.
+- **June 28, 2030**: Extended compliance deadline for certain self-service terminals, such as ATMs and ticket machines.
+
+Preparing early for these dates is essential to ensure compliance, avoid penalties, and meet market expectations for accessible products.
+
+### Expansion Beyond Web Accessibility
+
+The EAA builds on the Web Accessibility Directive, which originally focused on public sector websites and mobile applications, and extends accessibility requirements to the private sector. This expansion ensures that a broader range of digital and physical products in the private sector adhere to inclusive standards. The EAA’s implementation also benefits from the models and expert groups developed for the Web Accessibility Directive, promoting consistency in enforcement across the EU.
+
+## Meeting compliance requirements
+
+Making sure your business is compliant could be a significant amount of work that also requires a know-how of the field. This section will provide you steps to navigate the problem.
+
+### Automated tooling
+
+Nowadays there’s a plethora of tools to help tackle the a11y requirements. Most popular UI development frameworks such as Ember and Svelte document their solutions and integrations that help with a11y.
+
+- Code analysis - linting: Allows checking code for missing or misspelled HTML element attributes as the code is developed. It only allows to fix so many issues but they provide the quickest feedback and are the easiest to setup. They can be used as a starting point to accessibility. An example of such a tool is [ember-template-lint](https://github.com/ember-template-lint/ember-template-lint?tab=readme-ov-file).
+- Axe-core / e2e testing: Axe-core is a state-of-the-art accessibility analysis tool used by other tools. It provides analysis on a web page, unlike static code analysis, it inspects a web page state directly, providing more and more detailed information. It requires that your tests are able to render individual components or whole web pages for testing. It works well with tools like **Playwright** , **testem** , **storybook** which provide a browser environment for automated testing. An example of such integration is [axe-core/playwright](https://playwright.dev/docs/accessibility-testing).
+
+### Manual testing
+
+Manual auditing is required, because automated tools cannot uncover all potential issues, though they can significantly enhance and expedite the process. Elements such as focus management, keyboard behavior, and, most importantly, ensuring that screen readers are provided with correct metadata must be checked manually and evaluated within the broader context of a webpage.
+
+- [Axe extension](https://www.deque.com/axe/browser-extensions/): Axe is a browser extension developed by the creators of Axe-core. It allows you to run Axe-core directly in your browser to assist with manual audits. The extension comes in free and paid versions. The free version is sufficient for most needs, while the paid version includes additional features such as a “Guided test,” which provides a checklist and guidance for completing it—although this feature is available for free in another tool we’ll mention later.
+- [Accessibility Insights](https://accessibilityinsights.io/): Accessibility Insights, developed by Microsoft, is a completely free browser extension that may serve as the only tool you need for manual audits. It offers a guided assessment feature to assist you through the process and includes “ad-hoc” tools like “Tab stops,” which visualize where keyboard navigation moves during keyboard accessibility testing.
+
+### Screen readers
+
+Keyboard accessibility—the way keyboard navigation behaves—is the minimum requirement that needs to be supported. True accessibility, however, is achieved when a product is fully usable with the help of screen reading technology.
+
+Without going into details, here are some screen readers available across different operating systems:
+
+- [NVDA](https://www.nvaccess.org/download/): A third-party screen reader available for Windows.
+- [JAWS](https://www.freedomscientific.com/products/software/jaws/): A commercial screen reader for Windows.
+- **VoiceOver**: A built-in screen reader included with macOS.
+- [Orca](https://orca.gnome.org/): A screen reader for Linux systems, specifically those running the GNOME desktop environment.
+
+### Staff training
+
+Accessibility can’t simply be “done”; it must be an ongoing process integrated into the development cycle. Developers need at least a basic understanding of accessibility requirements, their implications, and how specific HTML attributes affect screen readers. Even if an app were to magically transform into an accessible product overnight, it would quickly deteriorate without conscious effort to maintain accessibility during updates. This is why educating teams on accessibility is essential. Articles, how-to guides, and [online courses](https://practical-accessibility.today/) are all great starting points, but accessibility must ultimately become an integral part of the development process—similar to code reviews, for example.
+
+### Costs of compliance
+
+Ensuring compliance with the European Accessibility Act involves several costs, which depend on the complexity of your web application. The process typically begins with an initial accessibility audit to identify areas requiring updates. Simpler applications may only require one-time investments to implement these updates, while more complex platforms may involve ongoing expenses for development, user testing, and the integration of assistive technologies. Training your team is another important factor, with costs associated with workshops or courses. Additionally, businesses should consider the long-term expenses of ongoing compliance monitoring and enhancing customer support for accessibility. Failing to comply may result in fines ranging from €5,000 to €20,000 _per violation_, with ongoing non-compliance penalties reaching as high as €1,000 per day. While these efforts require investment, the benefits include broader user engagement, reduced legal risks, and a strengthened reputation for inclusivity.
+
+## Quick intro to WCAG 2.2 (Levels A and AA) Success Criteria
+
+The WCAG 2.2 guidelines establish accessibility standards based on four key principles: **Perceivable**, **Operable**, **Understandable**, and **Robust**. These principles ensure content is accessible to all users, including those with disabilities.
+
+#### Perceivable
+
+- **Text Alternatives:** Provide text alternatives for all non-text content to convey the same information. Use brief descriptions for simple content and detailed descriptions when more context is needed, especially for control elements or user input fields. Mark purely decorative content to be ignored by assistive technologies.
+- **Adaptable:** Ensure content can adapt to different layouts without losing meaning. Content order should remain programmatically identifiable, and instructions shouldn’t rely solely on visual cues like color. Input fields collecting user information should be programmatically identifiable.
+- **Distinguishable:** Improve content visibility and audibility, maintaining a minimum contrast ratio of 4.5:1 for readability. Users should be able to resize text up to 200% without losing functionality. Limit reliance on images of text where text can achieve the same effect, and provide independent controls for audio that auto-plays.
+
+#### Operable
+
+- **Keyboard Accessible:** All functionality must be accessible via keyboard without requiring specific timings for keystrokes. Avoid trapping users within components and allow remapping of character shortcuts where applicable.
+- **Enough Time:** Provide options for users to control time limits, or turn off or pause moving content. Offer controls for blinking or scrolling content longer than five seconds, or stop it automatically.
+- **Seizures and Physical Reactions:** Avoid flashing content that could provoke seizures, keeping any flashes below the defined threshold.
+- **Navigable:** Support intuitive navigation through clear titles, bypass options for repetitive content, logical focus order, and contextually clear link purposes. Focus indicators should be visible, and elements receiving focus should not be obscured.
+- **Input Modalities:** Ensure interaction compatibility with various input methods, like single pointers or motion-based gestures. Components should be operable through either large or alternative touch targets (minimum 24x24 CSS pixels), with options to cancel actions if needed.
+
+#### Understandable
+
+- **Readable:** Specify the default language for each webpage to support accurate text rendering by assistive technologies. Indicate changes in language to maintain clarity, except in cases like proper names or technical terms.
+- **No automatic context switch:** Components shouldn’t change contexts automatically when receiving focus.
+- **Content order:** Ensure consistent relative order of navigational elements across pages
+- **Consistent identification:** Label elements with similar functions consistently across the site.
+- **User-initiated changes:** Warn users of any context changes triggered by their input.
+- **Input Assistance:** Help users avoid and correct errors by providing clear labels, descriptive instructions, and accessible error alerts. Detect errors automatically and offer correction suggestions unless security is compromised. For sensitive actions, implement safeguards against accidental submissions.
+
+#### Robust
+
+- **Name, Role, Value:** Ensure that user interface components (like buttons or input fields) are compatible with assistive technologies by making names, roles, states, and properties programmatically accessible. Use ARIA attributes and proper HTML markup to maintain accessibility.
+- **Status Messages:** Status updates, such as success messages or alerts, should be communicated to assistive technologies without disrupting the user’s focus. Utilize roles and properties like `role=status` or `role=alert` to achieve this.