Web Accessibility

Digital accessibility is not optional. Most countries have legal requirements: WCAG standards internationally, Section 508 in the US, EN 301 549 in the EU, RGAA in France. For private companies, it's a question of social responsibility and market opening. An inaccessible site excludes millions of users and exposes to legal risks.

Blackcube facilitates accessibility compliance through total control of generated HTML. Unlike CMSs that impose their HTML structure, Blackcube only injects content. The developer masters every tag, every attribute, every code detail. This architectural freedom allows guaranteeing compliance without fighting the system. Traditional CMSs can generate inaccessible HTML that's difficult to correct. With Blackcube, accessible HTML is natural because entirely under control.

Accessibility laws vary by country but generally follow WCAG standards. In the US, Section 508 applies to federal agencies. In the EU, EN 301 549 applies to public sector. Many countries have ADA-style laws for businesses. Non-compliance = possible financial sanctions.

Beyond obligation, accessibility opens the market: over 1 billion people worldwide have a disability. An inaccessible site excludes them.

1. Keyboard navigation benefits power users
2. High contrasts help in bright environments
3. Semantic structure improves SEO
4. Clear forms reduce errors

An accessible site improves experience for everyone:

Accessibility is not a cost, it's an investment that benefits all users.

CMSs can generate complex and difficult-to-master HTML. Themes, plugins, WYSIWYG editors produce code over which the developer has little control. Result: non-compliances difficult to correct.

1. Images without appropriate alt attribute
2. Inconsistent heading structure (h1, h2, h3)
3. Non-explicit links ("click here", "learn more")
4. Insufficient contrasts imposed by theme
5. Forms without associated labels
6. Impossible keyboard navigation in some components

Examples of common problems:

Correcting these problems requires modifying theme, overloading templates, adding JavaScript to compensate. Each CMS or theme update can break these corrections. Complex and expensive maintenance.

Accessibility plugins for WordPress or Drupal can help, but don't solve the problem at source. They add a layer on top of potentially non-compliant HTML. Fragile approach.

Blackcube only injects content via controller. Developer codes HTML exactly as desired. Each tag, each attribute is controlled.

Concrete example: displaying an image

1. img tag with appropriate attributes
2. Descriptive and relevant alt attribute
3. Semantic structure (figure, figcaption if necessary)
4. Explicit dimensions to avoid layout shift
5. Lazy loading if desired

Developer controls everything:

Heading hierarchy (h1, h2, h3) is managed directly in views. No surprise, no h3 arriving before h2 because of a misconfigured widget. Consistent and predictable structure.

Forms respect accessibility standards: each field has its correctly associated label, error messages are linked to concerned fields. No JavaScript needed to make a form accessible.

Developer manages keyboard navigation in views. Logical tab order, visible focus, appropriate clickable areas. No third-party JavaScript component blocking keyboard.

CSS is entirely under control. Respecting WCAG contrast ratios (4.5:1 for normal text, 3:1 for large text) becomes simple. No theme imposing non-compliant colors.

Blackcube stores images with their text content. Developer adds alt attribute in view by accessing appropriate block property. Relevant alternative text guaranteed.

Decorative images: empty but present alt attribute. Information-bearing images: descriptive alt. Complex images: detailed description via aria-describedby. Developer chooses according to context.

Links are coded directly in views with explicit labels. No automatically generated "click here". Developer writes labels that make sense out of context.

External links: ability to add aria-label or title to specify. Internal links: URLs generated via Url::to() with clear labels.

Each field has its associated label. Error messages linked via aria-describedby. Instructions and contextual help accessible. Client AND server-side validation.

Blackcube doesn't dictate form structure. Developer codes compliant forms according to business needs.

Navigation areas identified via appropriate tags (nav, header, main, footer). Skip links coded if necessary. Logical tab order.

Navigation menu: semantic list with ARIA states if necessary. Breadcrumb: nav with explicit aria-label. Everything is controlled.

BlocTypes define content structure. Developer codes views with appropriate semantics: section, article, aside according to context. No div soup imposed.

Blackcube's WYSIWYG editor is deliberately limited: bold, italic, lists, links. No heading management in WYSIWYG to avoid hierarchy errors. Headings are separate blocks with defined level.

1. aXe DevTools
2. WAVE
3. Lighthouse (Chrome DevTools)
4. Pa11y

Use automatic validation tools to detect errors:

These tools detect obvious errors: contrasts, missing alts, absent labels. But they don't replace manual tests.

Test with keyboard: navigate without mouse, verify everything is accessible. Test with screen readers: NVDA, JAWS, VoiceOver. Verify heading structure with HeadingsMap.

For official compliance, have a complete accessibility audit performed by certified organization. Audit verifies compliance with WCAG 2.1 or your region's specific standards. Blackcube facilitates compliance, but audit remains necessary for certification.

Once site is compliant, publish accessibility statement according to your region's requirements. Indicate compliance level (partially compliant, fully compliant), list possible exemptions, provide contact means to report problems.

Each new feature must be accessible from design. Integrate accessibility in development process, not afterwards. Accessibility tests in acceptance testing.

Train development team in accessibility best practices. Know WCAG criteria, know how to use validation tools, understand assistive technologies.

Train contributors to create accessible content: relevant alternative texts, explicit link labels, consistent content structure. Blackcube facilitates technically, but content remains human responsibility.

1. Total control: Blackcube doesn't generate HTML, developer masters everything
2. Accessible from design: No correction afterwards, good from start
3. Maintainability: No fight against system, clear and controlled code
4. Facilitated compliance: Semantic structure, accessible forms, clear navigation
5. Shared responsibility: Technical AND content must be accessible