DrupalCon Rotterdam 2026 Accessibility Assessment

Prepared for the Drupal Association

Prepared by Mike Gifford

11 September 2026

Assessment target: https://events.drupal.org/rotterdam2026

Status: Draft for review and action planning

The sampled site does not currently meet WCAG 2.2 Level AA. Confirmed failures in keyboard focus, form labeling and document structure also prevent a claim of conformance with the applicable web requirements of EN 301 549. The Drupal Association should correct the shared theme first, commission a complete audit of the registration and attendee journeys, and publish an accessibility statement that accurately describes the remaining limitations.

Executive summary

DrupalCon is a public expression of the Drupal project and its values. Its event site must work for disabled attendees, speakers, sponsors, volunteers and staff before they arrive at the venue. The Rotterdam 2026 site has useful accessibility foundations, including a skip link, semantic page regions, keyboard-reachable navigation and an appropriately labeled schedule filter disclosure. However, confirmed defects affect basic navigation and form use.

The most serious confirmed defect is the absence of a reliable visible focus indicator on important links. A keyboard user can move focus to calls to action without being able to see where focus is located. The newsletter form also relies on placeholders instead of persistent labels, and the homepage does not provide a first-level heading. These are not cosmetic defects. They affect whether users can perceive structure, identify controls and operate the site.

This report recommends a six-week initial remediation programme followed by continuing governance. The first release should correct shared theme defects. The next stage should test complete user journeys, including registration and any third-party services. Automated tests should prevent regressions, but the Association should not treat an automated score as evidence of conformance.

Purpose and intended audience

This report gives the Drupal Association an actionable assessment of the DrupalCon Rotterdam 2026 website. It is intended for Association leadership, event staff, digital product owners, designers, developers, content editors, procurement staff and vendors. It identifies confirmed barriers, explains their standards context, assigns responsibility and defines how remediation should be verified.

The report is a targeted technical assessment, not a certification. It supports immediate decisions while defining the additional work required before the Association can make a site-wide conformance claim.

Standards and policy context

WCAG 2.2

WCAG 2.2 Level AA is the recommended technical baseline for the event website. WCAG conformance applies to complete web pages and complete processes. A process such as buying a ticket cannot conform if an integrated registration or payment step introduces an inaccessible barrier, even when the event landing page is accessible.

Automated tools can identify some failures, but they cannot establish conformance. Manual evaluation is required for keyboard operation, focus visibility, reading order, alternative text quality, error recovery, zoom, user preferences and compatibility with assistive technologies.

EN 301 549

The EN 301 549 V1.1.1 PDF initially supplied for comparison dates from 2014 and should not be used as the current baseline. ETSI, CEN and CENELEC published EN 301 549 V4.1.1 in September 2026. Clause 9 incorporates the applicable WCAG 2.2 Level A and AA requirements for web pages. It also contains clause 9.7, a separate normative requirement concerning user preferences for web pages.

Publication as a European Standard does not by itself establish a presumption of conformity under European Union legislation. Annex ZB states that this presumption applies once the standard is cited in the Official Journal of the European Union under the relevant Directive. This report uses V4.1.1 as the current technical standard without making a legal claim about Official Journal citation or the applicability of a particular law to this event.

The confirmed WCAG failures also prevent conformance with the corresponding requirements in clause 9. EN 301 549 V4.1.1 additionally requires direct testing of focus obscuration, target size, dragging alternatives and user-preference non-interference.

User preferences under clause 9.7

Clause 9.7 requires a web page not to block a user agent mode that presents the page according to user preferences, and not to explicitly override preferences for documented platform accessibility features in that mode, unless following the preference would fundamentally alter the information or function. The standard identifies colour filters, contrast, text size, pointer size and the text cursor as examples. Its assessment method is inspection.

This is primarily a non-interference requirement. It does not require the event site to provide its own dark mode, contrast control, font-size control or preferences widget. Support for prefers-reduced-motion, prefers-contrast and prefers-color-scheme may improve the experience, but the absence of those media queries does not by itself establish a failure. The required question is whether browser or platform preference modes are blocked or explicitly overridden.

Scope and methodology

Pages sampled

• DrupalCon Rotterdam 2026 homepage

• DrupalCon Rotterdam 2026 session schedule

• Shared header, primary navigation, sponsor links, footer and cookie controls

• Newsletter subscription form

• Schedule disclosure and filters

Checks performed

• Keyboard traversal and visible focus inspection

• Heading and landmark inspection

• Accessible-name and form-label inspection

• Image alternative inspection

• ARIA relationship and disclosure-state inspection

• Duplicate ID inspection

• Review of responsive and preference-related risks visible from the implementation

Limits

The assessment did not complete registration, payment or newsletter submission because those actions would transmit data or create an external effect. It did not test every session, news article or venue page. It also did not complete a formal assistive-technology matrix, mobile device lab, 400 percent zoom audit, forced-colours audit or content review in every state. Findings described as risks require confirmation during the full audit.

Overall assessment

Conclusion. The site must not be represented as conforming to WCAG 2.2 AA or EN 301 549 at this stage. It has a repairable technical base, but confirmed Level A and AA failures affect common components.

Detailed findings

F01 Visible keyboard focus is missing on important links

Severity: Critical

Requirements: WCAG 2.2 SC 2.4.7; EN 301 549 9.2.4.7

Evidence. Keyboard testing found calls to action such as Explore the full program and Buy your ticket with outline-style set to none and no focus box shadow. The rendered view did not provide a reliable visual indication of the focused link.

User impact. A sighted keyboard user can lose their place and may be unable to navigate or register independently.

Recommended change. Define one theme-level :focus-visible treatment for links, buttons, form controls, summary elements and custom widgets. Remove component rules that suppress it. Use a multicolour or offset indicator that remains visible against light and dark backgrounds.

Responsibility. Theme maintainers implement. Designers approve the visual treatment. Accessibility lead tests all component states.

Acceptance test. Every interactive component displays a visible, non-clipped focus indicator at each breakpoint and at 200 and 400 percent zoom.

F02 Newsletter inputs do not have persistent labels

Severity: High

Requirements: WCAG SC 1.3.1 and 3.3.2; EN 9.1.3.1 and 9.3.3.2

Evidence. The email and name fields use Email Address * and Name * only as placeholder values. They have no associated label, aria-label or aria-labelledby.

User impact. Users can lose the field purpose after typing. Placeholder text may be hard to perceive and does not provide reliable instructions.

Recommended change. Add visible label elements linked with for and id. Apply native required attributes, explain the required-field convention, and retain concise help and error text beside each field.

Responsibility. Webform or integration maintainer implements. Content owner supplies clear wording. Accessibility lead verifies error states.

Acceptance test. Each field has a visible persistent label, programmatic required state, specific error association and understandable correction guidance.

F03 Homepage has no first-level heading

Severity: High

Requirements: WCAG SC 1.3.1; EN 9.1.3.1

Evidence. The visible homepage hierarchy starts with an h3 for DrupalCon Orlando 2027. The main Rotterdam message is also an h3, while later sponsor headings are h2 elements. No h1 is present.

User impact. Screen-reader users and other users navigating by headings receive a misleading outline and cannot locate the page topic reliably.

Recommended change. Provide one descriptive h1 in main content. Treat the next-event promotion as navigation or ordinary text. Use h2 for major homepage sections and style headings with classes rather than selecting levels for appearance.

Responsibility. Theme maintainer changes shared markup. Content designer confirms page hierarchy. Editors follow a documented heading model.

Acceptance test. Each representative page has one clear h1 and a logical nested heading hierarchy.

F04 Personal information inputs omit autocomplete tokens

Severity: Medium

Requirements: WCAG SC 1.3.5; EN 9.1.3.5

Evidence. The newsletter collects email and name data but does not include autocomplete=email and autocomplete=name or given-name.

User impact. Users with cognitive, motor or memory-related disabilities lose browser-supported input assistance.

Recommended change. Add standard HTML autocomplete tokens that match the actual information requested.

Responsibility. Webform or integration maintainer implements. Accessibility lead confirms values and browser behaviour.

Acceptance test. Every field collecting a recognized personal-data purpose exposes the correct autocomplete token.

F05 Shared markup contains duplicate IDs

Severity: Medium

Requirements: Implementation defect with possible impact on WCAG SC 1.3.1 and 4.1.2

Evidence. Both sampled pages repeat block-drupalcon-branding and block-conferencelogo.

User impact. Duplicate IDs can cause fragment links, labels, ARIA references and JavaScript selectors to resolve unpredictably.

Recommended change. Remove hard-coded IDs from reusable templates or generate a unique Drupal-derived ID. Check that each ARIA ID reference resolves to exactly one element.

Responsibility. Theme maintainers implement. Quality engineering adds an automated duplicate-ID check.

Acceptance test. No rendered page contains a duplicate non-empty ID, and every ID reference resolves uniquely.

F06 Several image alternatives expose internal naming

Severity: Medium

Requirements: WCAG SC 1.1.1; EN 9.1.1.1

Evidence. Examples include Acquia_logo, dropsolid-logo, 1xinternet_logo and A&B Icon_new brand.

User impact. Screen-reader users hear file-management language instead of a concise description of the link or image purpose.

Recommended change. Use the sponsor name as the alternative when the image is the only content of a sponsor link. Use empty alternatives for decorative images. Describe event photographs only when their content adds information not provided nearby.

Responsibility. Content editors correct media data. Theme maintainers prevent decorative icons from entering accessible names. Sponsors may review brand names but should not dictate inaccessible text.

Acceptance test. Image alternatives communicate the same purpose as the image without filenames, underscores or redundant words such as image or logo.

F07 Cookie banner may obscure focused content

Severity: Medium risk

Requirements: WCAG 2.2 SC 2.4.11; EN 301 549 V4.1.1 9.2.4.11

Evidence. The persistent cookie banner occupies the bottom of the viewport while underlying footer controls remain in the keyboard order. Full zoom and responsive testing is required to confirm the extent of obscuration.

User impact. A keyboard user may focus a control that is partially or completely hidden behind the banner.

Recommended change. Keep the banner in document flow where practical, or reserve space equal to its actual height. Ensure Reject is as easy to find and operate as Accept. Provide a way to reopen preferences.

Responsibility. Consent-platform owner and theme maintainers implement. Privacy owner approves choices. Accessibility lead tests focus visibility.

Acceptance test. No focused element is entirely hidden at supported breakpoints, 200 percent zoom or 400 percent zoom.

F08 Dynamic form errors and confirmations are not yet verified

Severity: Medium risk

Requirements: WCAG SC 3.3.1, 3.3.3 and 4.1.3; EN corresponding clauses

Evidence. The newsletter form disables native validation and provides initially hidden response containers. Submission behaviour was outside the targeted test.

User impact. Errors or success messages may not be announced or associated with the relevant field.

Recommended change. Provide an error summary, field-level error text, aria-invalid only when appropriate, preserved valid input and a clear success confirmation. Test the third-party response in multiple screen readers.

Responsibility. Integration maintainer implements. Vendor supports accessible responses. Accessibility lead verifies.

Acceptance test. Empty, invalid, corrected and successful submissions can be completed and understood with keyboard and screen reader.

F09 Conformance with user preference requirements is not established

Severity: Not tested

Requirements: EN 301 549 V4.1.1 9.7

Evidence. The targeted assessment did not run the site through the platform and browser modes needed to test clause 9.7. The earlier inspection found no confirmed evidence of preference-specific media rules, but clause 9.7 does not require those rules. Their absence is not evidence of failure.

User impact. If the site blocks forced colours, text enlargement, colour filters, large pointers or text cursors, users may be unable to use the presentation selected through their browser or operating system.

Recommended change. Inspect the site in preference-enforcing modes. Search the theme and component styles for explicit overrides, including forced-color-adjust: none. Remove unjustified overrides. Document any claimed essential exception and verify that it is limited to the smallest necessary component.

Responsibility. Theme maintainers inspect and correct CSS. Accessibility lead runs and records the clause 9.7 procedure. Product owner approves any essentiality claim, with technical and accessibility evidence.

Acceptance test. The page does not block a user-agent preference mode and does not explicitly override documented platform accessibility preferences unless the override is essential to the information or function.

Implementation examples

Shared focus treatment

:where(a, button, input, select, textarea, summary,
[tabindex]:not([tabindex="-1"])):focus-visible {
outline: 3px solid #ffbf47;
outline-offset: 3px;
box-shadow: 0 0 0 2px #002847;
}

The exact colours must be tested against each component background. Component styles must not remove this treatment. The test must include clipped containers, sticky regions and the cookie banner.

Newsletter field

<label for="mce-EMAIL">Email address <span aria-hidden="true">*</span></label>
<input type="email" id="mce-EMAIL" name="EMAIL"
autocomplete="email" required
aria-describedby="newsletter-required newsletter-email-help">
<p id="newsletter-email-help">Enter the address where you want DrupalCon news.</p>

Homepage structure

<main id="main-content">
<h1>DrupalCon Rotterdam 2026</h1>
<section aria-labelledby="why-attend-heading">
<h2 id="why-attend-heading">Why attend DrupalCon Rotterdam</h2>
...
</section>
</main>

Schedule results announcement

<p id="schedule-result-count" aria-live="polite">
24 sessions match the selected filters.
</p>

User preference non interference

The clearest implementation risk identified by clause 9.7 is an explicit CSS override such as forced-color-adjust: none. Do not use it unless the presentation cannot preserve essential information or function in forced-colours mode. Most event-site components should allow the browser to substitute system colours.

@media (forced-colors: active) {
:focus-visible {
outline: 3px solid Highlight;
}

button, input, select, textarea {
color: ButtonText;
background: ButtonFace;
border: 2px solid ButtonText;
}
}

This example can improve compatibility, but clause 9.7 does not require this exact CSS. A page can pass without a forced-colours media query if it does not block or override the user agent mode. Dark mode and prefers-contrast support should be recorded as enhancements unless another applicable requirement makes them necessary.

Requirements for the full audit

The Association should test complete tasks rather than treating each URL as an independent unit. WCAG conformance applies to complete processes, including third-party steps that the Association requires attendees to use.

Manual test matrix

Responsibilities

Accessibility work fails when everyone is described as responsible but no role is accountable. The Association should name individuals for the roles below. Vendors remain responsible for fixing their products, but the Association remains accountable for the attendee experience and for providing an alternative when a required vendor service is inaccessible.

Responsibility matrix

A means accountable, R responsible, C consulted and I informed. The named accountable role must resolve conflicts and accept any documented residual risk.

Remediation roadmap

Release gates and evidence

Minimum release gates

• No unresolved critical barrier in a required attendee journey.

• No unresolved Level A or AA failure introduced by the release.

• Keyboard and 400 percent zoom journeys pass on representative pages.

• Automated checks pass, with every exception linked to a reviewed record.

• Third-party changes are tested before deployment, not accepted on vendor assurance alone.

• Known limitations and accessible alternatives are updated before public release.

Evidence record for each finding

• URL, component and tested state

• Date, browser, operating system and assistive technology

• Applicable success criterion or EN clause

• Steps to reproduce, expected result and actual result

• User impact and affected journey

• Code or content correction

• Retest evidence and reviewer

A screenshot can support a finding but is not sufficient by itself. Evidence should describe the interaction, programmatic state and expected outcome so another reviewer can reproduce it.

Automated testing and continuous integration

Use axe-core, HTML validation and targeted Playwright assertions as regression controls. Do not publish an automated score as a conformance score. A page with a perfect automated result may still have inaccessible focus behaviour, misleading alternative text, broken reading order or an unusable registration process.

test('homepage has one first-level heading', async ({ page }) => {
await page.goto('/rotterdam2026');
await expect(page.locator('h1')).toHaveCount(1);
});

test('newsletter fields have visible labels', async ({ page }) => {
await page.goto('/rotterdam2026');
await expect(page.getByLabel('Email address')).toBeVisible();
await expect(page.getByLabel('Name')).toBeVisible();
});

CI should retain machine-readable results and human-readable summaries. The product owner should review recurring defects by component so that teams fix the source rather than patching individual pages repeatedly.

Procurement and third-party services

The Association should require vendors to demonstrate accessibility in the actual configuration used for DrupalCon. A VPAT or Accessibility Conformance Report can inform procurement, but it does not establish that the deployed registration, payment, consent, map or video experience is accessible.

• Contracts should name WCAG 2.2 AA and applicable EN 301 549 requirements.

• Vendors should provide current test evidence for the configured service.

• Contracts should define defect severity, response time and remediation obligations.

• The Association should retain the right to test and to require corrections.

• A required service should have an equivalent accessible route when the vendor cannot correct a barrier in time.

• Event staff should know how to support the alternative route without requiring a disabled person to explain accessibility law or disclose unnecessary personal information.

Accessibility statement requirements

The website should publish a statement before registration is promoted broadly. It should identify the conformance target, assessment date, methods, tested scope, known limitations, contact route and expected response time. It should also explain how to request event information or complete registration through an accessible alternative.

Suggested opening text

The Drupal Association aims for the DrupalCon Rotterdam 2026 website and registration process to meet WCAG 2.2 Level AA and the applicable web requirements of EN 301 549. We are testing the site throughout its development. This statement describes the current limitations and the work underway to correct them.

The statement must not say fully accessible, compliant or certified unless a complete assessment supports that claim. Update it whenever a material barrier is found, corrected or introduced by a third-party change.

Recommended governance after Rotterdam

The Association can reduce repeated remediation by treating the DrupalCon theme and its components as a maintained product. Shared defects should be corrected upstream and tested once at the component level, then verified in each event configuration.

1. Maintain an accessible component inventory for navigation, hero content, cards, sponsor displays, forms, schedules, disclosures, consent controls and media.

2. Require accessibility acceptance criteria in every related issue and pull request.

3. Include disabled contributors and attendees in structured usability testing and compensate them for specialist work.

4. Review accessibility at content design, implementation, release and post-launch stages.

5. Publish known limitations and progress instead of reducing accessibility to a pass or fail score.

6. Carry improvements into the next DrupalCon site and remove event-specific forks where they prevent fixes from propagating.

Positive foundations to retain

• The document language is declared as English.

• Page titles are descriptive.

• A Skip to main content link is the first keyboard target.

• Major regions use header, main, footer and navigation semantics.

• The schedule page has an appropriate first-level heading.

• The schedule filter button exposes aria-expanded and aria-controls.

• Track controls use fieldsets, legends and associated checkbox labels.

• Cookie choices are implemented as buttons with understandable names.

• The sampled content contained no autoplaying audio or video.

These foundations should be preserved during remediation. They do not cancel the confirmed failures, because WCAG conformance requires every applicable Level A and AA criterion to pass.

Recommended decision

The Drupal Association should accept the confirmed findings, appoint a digital product owner and accessibility lead, and begin the shared-theme remediation immediately. The Association should then commission testing of complete attendee journeys and publish an accessibility statement before describing the site as conformant. Critical and high barriers should close before registration promotion expands. Any remaining barrier in a required journey should have a documented accessible alternative, owner and correction date.

References

1. W3C Web Content Accessibility Guidelines WCAG 2.2

2. W3C Understanding Focus Visible

3. ETSI EN 301 549 V3.2.1

4. ETSI EN 301 549 V4.1.1

5. DrupalCon Rotterdam 2026

6. DrupalCon Rotterdam 2026 Session Schedule