Advanced
Accessibility
Problems

Jewish Museum Berlin
jmberlin.de

• March 2020: Complete Redesign (Drupal 7)
  Theme worked in IE 11
  Some new techniques were not available back then, e.g. container queries, <dialog>, inert.
• April 2021: Accessibility Test, Jan Hellbusch
• April 2024: Finally migrated to Drupal 10
  Mostly same CSS as before, but new theme, changes in Drupal
• June 2024: Accessibility Test, BFIT
• January 2025: Accessibility Test, Jan Hellbusch

Jan Hellbusch is a well known Accessibility Consultant in Germany. He has written several books about the topic.
hellbusch.de

BFIT is the German »Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik«.
www.bfit-bund.de

All examples are taken from real accessibility tests for the Jewish Museum Berlin – jmberlin.de.

This session does not include all the issues that were found. Just the more interesting ones.

The idea is to show some examples that can probably benefit your websites as well.

Current state on our side: Some changes are online. Some are on stage. Some stuff needs rebuilding of components, which is planned for the summer.

Main links

• Latest version of the Web Content Accessibility Guidelines (WCAG) 2.2
• Patterns of the ARIA Authoring Practices Guide
  They have examples for Accordions, Alerts, Breadcrumbs, Carousels, Sliders, Tooltips, etc.

Granted, these three pages exist because we have to have them. Because like most museums this one is also funded in part by the state.

But then there is also …

Problem: This looks fine. Until you check the contrast. Here we have:

• White on Red: 3.76:1
• White on Blue: 16.83:1
• White on Berry: 7.3:1

Contrast Ratio needs to be at least 4.5:1.

HTML, old code

HTML, corrected code with lang attributes

Problem: Here we didn’t use a list <ul> for search results.

HTML, old code, a few years back

Problem: In screen readers you do not know what the buttons are for.

HTML, new code

HTML, old code, just recently

Problems: The aria-label for the english page was in German. / The aria-label was of course redundant.

HTML, new code

Keep in mind: No ARIA is better than Bad ARIA.

See also: aria-label is a letdown
»All in all, 34% of aria-label uses we reviewed are likely incorrect.«

HTML

The problem was that we hadn’t translated »page« for the German pages.

Problem: When there is more than one <nav> on the page each one (except for the main navigation) needs an aria-label.

Note:»Past event« needs to be a heading.

So now it is a <h2>.

Personally I am not happy with this change as the h2 is not the heading for the rest of the main text.

HTML, old code

HTML, new code

»The <hgroup> HTML element represents a heading and related content. It groups a single <h1>–<h6> element with one or more <p>.«

»The <hgroup> element allows the grouping of a heading with any secondary content, such as subheadings, an alternative title, or tagline. Each of these types of content represented as a <p> element within the <hgroup>.«

See mdn.

The hgroup element was dropped from the HTML5 standard. But it is still alive in the HTML Living Standard of the WHATWG. All major browsers support <hgroup> since 2015.

See W3C vs. WHATWG HTML5 Specs – The Differences Documented

HTML, old code

Problem: The link has no context.

HTML, possible solution 1

HTML, current code

Note: The main content is grouped twice, once with a <main> element and once in an <article> element. This is redundant in screen readers.
The article element should be removed – or given the role "none".

HTML, old code

Jan Hellbusch writes: Success criterion 1.3.1 requires structure. The HTML specification requires »paragraphs«:
Accordingly, all formulating content (»phrasing content«) belongs in a paragraph. However, a paragraph is not to be equated with a p-element, but with a structuring element.

HTML, current code

Problem 1: If a user tabs to a card outside the viewport he will jump to an already turned card.

Problem 2: An active element is required (which can be triggered via mouse-over). / While automatic turning is OK for mouse users, it may only be triggered for keyboard users after pressing Enter.
Note: For keyboard users, the expanding (flipping) button should somehow remain visible after the first flip.

HTML, proposed code

Problem: popover is relatively new. We will implement this differently.

About popover:

»The Popover API provides developers with a mechanism for displaying popover content on top of other page content. Popover content can be controlled either declaratively using HTML attributes, or via JavaScript.«

»The popover can be "light dismissed" – this means that you can hide the popover by clicking outside it. / The popover can also be closed, using browser-specific mechanisms such as pressing the Esc key.«
developer.mozilla.org

Problem 1: The mandatory fields are marked a total of four times (*, required attribute, aria-required attribute, text behind the input field):

HTML, example code

• The aria-required attribute must be removed (it is ignored by browsers because of the required attribute, but the ARIA-in-HTML specification prohibits redundancy).
• Note: The text behind the input field is redundant to the label, it offers no help. I would remove the redundant text.

Problem 2: Error messages are displayed as a tool tip on the input field. However, these disappear as soon as they leave the field of view.

(I’ll need to check this. They might mean the browser tool tips.)

Problem 3: There is again some structure missing.

HTML, proposed code version 1

HTML, proposed code version 2

HTML, current code

German tends to have quite long words, which can lead to empty space at the end of lines.

With CSS we could add hyphens: auto, but this leads to unwanted hyphenation.

For years, the editors are adding &shy; manually to have full control where breaks can occur.

Problem for editors: In Drupal 10 the new CKEditor decides to swap the &shy; to an invisible character. These characters do hyphenate in the background. But editors can’t see what is going on.

Now we have to rebuild a fine HTML feature with stupid workarounds.

HTML, code within CKEditor

HTML, on the actual page

Jan Hellbusch testet this last week:

• JAWS got better last year. The gaps got smaller, but you still hear a different pronunciation.
• In NVDA the word "Bildungsprogramm" is pronounced "Bildungs Silbentrennzeichen [=hyphen] programm" ausgesprochen. This happens everywhere on the site.

Suggested solution: use <wbr> instead of &shy;.

<wbr> does break the word. But in contrast to &shy; you do not get a hyphen. This is worse for people who can see. So we will not use this.

Usable solution? Still looking for one.

Note: There are some JavaScript solutions out there. But as far as I can tell they just add &shy; to the code. Some tools give us more control than CSS hyphens, but we still have the screen reader problem.

Our »infopanels« are currently styled as definition lists. That looks ok. But …

HTML, current code

Problem: The dl elements are readable in screen readers. But they do not any semantics. They have no role.

See https://www.w3.org/TR/html-aria/#el-dl

HTML, proposed code

New problems: The items need to be either in a p or in a list. / The heading may change because of the context (in our case: h3 or h4).

HTML, current code

This is basically ok. But this leads to very long link texts in screen readers.

HTML, our code

HTML, proposed code in 2021

And then toggle aria-expanded and hidden with JavaScript.

The problem with summary: The summary element may contain headings, but screen readers can’t access the heading. E.g. when you jump from hx to hx with the key H, you will not find the heading inside the summary.

The problem may be the default style display: list-item. If you reset that part then the screen reader will find the heading. This only works when there is only one element in the summary.

CSS

Still a problem: Cause our summary contains a heading and two SVG.

HTML, our code

Solution: The SVG need to move inside the h3.

This needs a little bit more work, cause at the moment the editors write the heading directly into the textfield, as they need to choose h2, h3 or h4.

These teasers are implemented as a list. It contains almost always two or three teaser elements. Except in that one week when BFIT testet the site.

Note: »Home page: The large graphic below the header is labelled as a list with only one entry.«

Solution: Differentiate and either display an ul or a div.

New problem: We have several places where in 99% of cases there are multiple elements, but it can happen that there is only one item.

HTML, current code

Note: It has been noticed that the designation also includes the indication of the author. There is no requirement that explicitly prohibits this, but this is about the text alternative that should indicate the purpose of the graphic. Therefore, information of this kind should be placed outside the <figcaption>.

HTML, proposed better code

Problem 1: People can tab out of the layers and reach the content in the background.

One solution for that would be an old focustrap.

An easier solution is probably inert, which all major browsers support since April 2023 (last browser was Firefox).

When the search layer is opened the focus jumps to the input field. As it should be.

But we have other layers that open and close.

Problem 2: The focus needs to go into that layer.

Solution: The headline (or heading group) should have an autofocus attribute.

Problem 3: The new layers are currently simple divs.

Solution: The new layer should be a dialog element and opened with showModal(). The buttons must be labelled as menu buttons:
<button aria-haspopup="dialog">…</button>

Problem 4: Currently there is a list for the buttons. The new layers are placed after the ul. This is not the correct order for screen readers.

Solution: Place the new layer directly after the button.

We have one rather regular slider. One where the first element can be bigger (one element instead of three on desktop). And one carousel on the frontpage. All with some variations in responsive sizes.

HTML, better code

HTML, current code

HTML, better accessibility without figcaption

Problem: The text is set in white on a photo. There is a shadowed area over the photo. But depending on the photo the contrast between text and some parts of the photo is not high enough.
We can’t really change this without breaking the design. Needs a redesign.