Service Design – FAQ

1. Web page structure

What page sections need to be defined with landmarks?

To meet the WCAG 1.3.1 Information and Relationships, you should at minimum designate the banner and footer sections, if they exist on the age, and the main content.

You may also want to mark up navigation and search sections, although these are not always mandatory to designate given that they can often be recognized by their other attributes as well. Finally, there is discussion in the module 3 and 4 material on how to use regions to make menus, accordions and other dynamic content easier for users to understand and navigate.

The landmarks can be assigned with the role attributes or their equivalent HTML5 tags listed below:

Banner: role=”banner” or <header>
Main: role=”main” or <main>
Footer: role=”contentinfo” or <footer>

Other common landmarks:

Search: role=”search”
Navigation: role=”navigation” or <nav>
Region: role=”region” or <section>
Complementary: role=”complementary” or <aside>

The two landmarked regions below are semantically identical:

<div role=banner>…<div role=”search”> …</div><div role=”navigation”> … </div></div>
<banner>…<div role=”search”>…</div><nav>…</nav></banner>

Do I always have to use a sub-heading level that is one step lower than the parent heading (I.e. H3 after a H2)?

It is strongly recommended that you do so, as conforming to this rule will greatly improve your web site’s usability for non-visual users who have to rely on landmarks and headings to mentally parse the semantic structure on each page. When heading levels deviate from this rule and ascend or descend haphazardly, it is more difficult for users to grasp the page semantic structure. Think of the contents section of a book as a comparison: You want the heading levels to be logically nested in relation to one another for the contents to be a useful reference to the book.

That said, WCAG 2.1 does not mandate that headings be nested in a step-by-step descending order. An H2 can be followed by an H4. But if the headings are semantically at the same level, they must be avowed the same H level, or the user will perceive incorrectly that the content under one heading is nested inside the other while in reality they are parallel. For instance:

<h2>Tickets</h2>

<h4>The different kinds of ticket</h4>

<h4>Reserving tickets in advance</h4>

<h5>Cancellation policy</h5>

<h4>Purchasing tickets</h4>

<h5>Returns policy</h5>

Vs.

<h2>Tickets</h2>

<h2>The different kinds of ticket </h2>

<h2>Reserving tickets in advance </h2>

<h5>Cancellation policy</h5>

<h3>Purchasing tickets</h3>

<h4>Returns policy</h4>

In the first example, the H4 headings are clearly subsections of Tickets. Too, they have each one sub section of their own, where the topic is further detailed. In the latter example, the second and third H2 appear to be parallel to tickets, and so the tickets heading is expected to have content not belonging to any of these categories. What might that be? The ticket purchases, in turn, seems to be a sub section of ticket reservations. This latter structure is clearly incongruent with the intended logical structure of the page and is hence incorrectly defined.

NOTE that the heading level is independent of the visual style of the heading. The level is set according to the logical heading structure of the page; visual styling – e.g. how prominent a particular heading appears visually – can be set altogether apart from the heading levels.

2. Links

What is the role of the alternative text (ALT) on image links?

If the image link is only provided with one accessible name, then the purpose of the ALT text is to describe the link target or the link’s purpose, not the image itself. That is, if the ALT is written for the image content, assistive technology users will be left uninformed of the link’s purpose and target. To this end, one can think of the ALT as equivalent to a link text.

The Alt can describe the image (shown, for instance, in case it fails to load) if the link element has an appropriate alternative accessible name, such as an aria-label, which caters to screen reader users and describes the link’s purpose.

For example:

3. Visual Design

The keyboard focus indicator that my web page displays has an abhorrently poor contrast on some systems/browsers. How can I control this?

Firstly, there is no need to control or adjust how the standard keyboard focus indicator appears. Its style and colour is, be default, dictated by the browser and/or operating system. for this reason, when you permit elements to show the default focus indicator, you always pass WCAG irrespective of how the indicator is rendered on-screen.

If, however, you do want to control its appearance, you can do so (altering the :focus CSS state and its outline property, which can be adjusted or removed). But if you do alter the focus state appearance, you do assume the responsibility that it fulfills WCAG 1.4.11.

Alkuperäinen versio: Tero Pesonen / Siteimprove
Luotu: 4.3.2021