Fix accessibility of toolbar toggler

[Chi-teck]

Symfony version affected: master

Description
Here is the currently used markup of "Show toolbar" link.

<a href="#" title="Show Symfony toolbar" tabindex="-1" id="sfToolbarMiniToggler-95d68f" accesskey="D">
    <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">
        <!-- SVG image -->
    </svg>
</a>

I think it has a few semantic and accessibility issues.

1. First of all, using <a href="#"/> here is not semantically correct, because it is not a link but button. It needs to be rendered with <button/> tag or at least have role="button".
2. tabindex=-1. Why? It makes the toggler not reachable through keyboard. Note that accesskey cannot be considered as a replacement for tabindex because it may conflict with a system or browser keyboard shortcut. That's what is happening on my local machine. See accessibility concerns.
3. aria-expanded attribute is missing. Also we may consider adding aria-controls and aria-haspopup attributes.
4. SVG images need aria-hidden=true and focusable=false attributes.

[Chi-teck]

Also we may consider adding aria-controls and aria-haspopup attributes.

I am not quite sure about this. @fuzzbomb can you advise on these attributes?

[fuzzbomb]

@Chi-teck - I'm not familiar with this particular button, and the <a> snippet you cite doesn't show the whole picture. What's actually being controlled here? Screenshots before and after pressing it would help.

If this is a simple "show toolbar" button then your points are mostly fine. In detail:

1. First of all, using <a href="#"/> here is not semantically correct, because it is not a link but button. It needs to be rendered with tag or at least have role="button".

Correct. A <button type="button"> has the correct semantics for a simple show/hide disclosure control. It isn't a link. The basic difference is:

• A link points somewhere, activating it takes you there. (The href="#" in the snippet you cite points to the start of the document.)
• Buttons: you press it, and something happens. Don't forget the type="button" attribute. The default type is "submit", which isn't right for a disclosure control.

There isn't much point in <a role="button">. Just use a proper <button> per the first rule of using ARIA.

2. tabindex=-1. Why? It makes the toggler not reachable through keyboard.

Correct. There's no good reason to remove this from the tabbing order.

Note that accesskey cannot be considered as a replacement for tabindex because it may conflict with a system or browser keyboard shortcut. That's what is happening on my local machine.

Correct. That's a common problem. It can also conflict with browser add-ons, which is a huge unknown. Accesskey also suffers from poor discoverability, and can also be awkward to operate even if you know it's there.

3. aria-expanded attribute is missing. Also we may consider adding aria-controls and aria-haspopup attributes.

I can't confirm that until I know exactly what it controls.

• aria-expanded IS appropriate for a simple disclosure control (but it wouldn't be appropriate for a button which caused a dialog to open.)
• aria-controls - IS appropriate for a simple disclosure control. Note that it isn't widely supported by much assistive tech yet (JAWS only AFAIK, and it depends on a user setting.) I think it's still worth putting in place.
• aria-haspopup is NOT appropriate for a simple disclosure control.
  • Only use this attribute if the thing being controlled has one of the prescribed roles in WAI-ARIA 1.1 - aria-haspopup.
  • To date, support is lacking for anything other than aria-haspopup="true", which is only to be used when the thing being controlled has the menu role.
  • For a simple disclosure button, the presence of aria-expanded="false" is sufficient to convey that more content will be revealed. You don't need aria-haspopup as well.

4. SVG images needs aria-hidden=true and focusable=false attributes.

• aria-hidden="true". Not always. It depends what is inside the <svg> element, but your snippet doesn't show that.
  • It is possible for text inside the <svg> to provide the accessible name for a button, for example a <title> element. It takes precedence over the <button title=""> element, which might not be what you want. (Some graphics applications abuse the SVG <titile> attribute by populating it with the name of the application which created the SVG.)
  • Using <svg aria-hidden="true"> can be handy, as it will result in the <button title=""> attribute being used as the accessible name of the button. (Assuming there's no other text inside the button).
• In this case it's probably a good idea to put focusable=false on there. Buttons aren't allowed to have interactive children (ARIA refers to this as "children presentational").

[Chi-teck]

Here are the screenshots. When toolbar is "closed" it only shows a link with Symfony logo (SVG) in the right bottom corner of the page. When you click the icon it shows the toolbar along the bottom of the page and the logo icon gets replaced with the close icon.

Both SVG icons have no title element inside. So I assume button's title attribute will be used as accessible name of the button.

[Chi-teck]

SVG images need aria-hidden=true and focusable=false attributes.

That would be tricky as they are stored in external files and can potentially be used in a different context.
https://github.com/symfony/symfony/blob/v5.1.3/src/Symfony/Bundle/WebProfilerBundle/Resources/views/Profiler/toolbar.html.twig#L4

The workaround could be something like this

{{ include('@WebProfiler/Icon/symfony.svg')|replace({'<svg': '<svg aria-hidden="true" focusable="false" '})|raw }}

[stof]

would it work if aria-hidden="true" was applied on a span wrapping the svg instead ?

[Chi-teck]

@stof it would work for aria-hidden but focusable needs to be set on SVG.

[Chi-teck]

aria-haspopup is NOT appropriate for a simple disclosure control.

Turns out the switcher is a bit more complicated because it consists of two links. The "open" link is outside of toolbar while the "close" link is inside. Visually the links look like a single switch button because they are rendered in the same place (right bottom corner).

[Chi-teck]

{{ include('@WebProfiler/Icon/symfony.svg')|replace({'<svg': '<svg aria-hidden="true" focusable="false" '})|raw }}

Well, we could simply use CSS background instead.

[fuzzbomb]

Both SVG icons have no title element inside. So I assume button's title attribute will be used as accessible name of the button.

Correct, assuming there is no other text inside the button. The accessible naming precedence is aria-labelledby > aria-label > the text from the button's content > the button's title attribute. The first non-empty source wins.

You don't have to set these attributes in Twig. You can do it as part of the JS initialization. This toolbar thing does nothing without Javascript, right?

Certainly the dynamic ARIA attributes (aria-expanded) should be initialized in JS, not the HTML source.

Well, we could simply use CSS background instead.

Except the button is content, not decoration. CSS background images are stripped out by Firefox and Internet Explorer when a Windows high-contrast theme is enabled. Such users need to know what the button is for, and what state it is in. But when using a CSS background image, they either won't know there's a button there at all, or else they will see a button border but won't know what it means.

It would be a lot safer if you have a real text label inside the button.

aria-haspopup is NOT appropriate for a simple disclosure control.

Turns out the switcher is a bit more complicated because it consists of two links. The "open" link is outside of toolbar while the "close" link is inside. Visually the links look like a single switch button because they are rendered in the same place (right bottom corner).

Aha. That's why I was hesitant to advise on the ARIA attributes, before seeing the markup.

aria-haspopup is still not appropriate, because the thing being revealed is not an application menu, dialog, or listbox. It looks more like a summary of some status/performance information - so that warrants a simple disclosure widget.

It'll simplify a LOT if you replace these two "links" with a single proper <button>. Everything I've advised up to this point was based on the assumption that this was a single button, and I can't advise using anything else.

[Chi-teck]

because the thing being revealed is not an application menu, dialog, or listbox

I am not sure if it matters but all items in the toolbar are clickable. They are linked to corresponding pages in profiler. So it's kind of menu.

[fuzzbomb]

I am not sure if it matters but all items in the toolbar are clickable. [...] So it's kind of menu.

No, that doesn't matter. The fact that an area contains clickable controls does not make it a menu. You can't just throw ARIA semantics at it willy-nilly. A menu in ARIA is like the "File, Edit, View, ..., Help" WIMP application menus. Unless you're building Google Docs, you don't need it.

They are linked to corresponding pages in profiler.

So they are links, which direct you elsewhere. HTML semantics suffice for that. If you want them to be understood as links, then don't use the ARIA menu role.