1878274 - Accesibility review for cookie banner

Status: RESOLVED FIXED

(www.mozilla.org :: General, enhancement)

Description

[Alex Gibson [:agibson]]

Request for an accessibility review for a cookie banner that will appear on www.mozilla.org. There are two areas for review, the banner itself and also a cookie settings page. Both are available on the demo URLs below.

Banner: https://www-demo1.allizom.org/en-US/
Settings page: https://www-demo1.allizom.org/en-US/privacy/websites/cookie-settings/

Marking as employee confidential for now, since the banner is still in development and subject to change, and has not yet been communicated publicly.

Comment 1

[James Teh [:Jamie]]

Thanks for requesting accessibility review.

Normally, when you set the a11y-review flag (which of course you can't do here - I'll look into getting that fixed), you get a comment template to fill in. Here are the relevant bits of that for this request:

The accessibility team has developed the Mozilla Accessibility Release Guidelines which outline what is needed to make user interfaces accessible:
https://wiki.mozilla.org/Accessibility/Guidelines
Please describe the accessibility guidelines you considered and what steps you've taken to address them:

Describe any areas of concern to which you want the accessibility team to give special attention:

Thanks!

Comment 2

[Alex Gibson [:agibson]]

Thanks James! Added detail below as per the questions:

Cookie banner

Please describe the accessibility guidelines you considered and what steps you've taken to address them:

HTML markup:

• I've tried to make the markup as semantic as possible, using an <aside> element for the main cookie banner component (since it's only indirectly related to the page content). I have used standard heading/paragraph elements, and have also used regular <button> elements for accept / reject to make sure they are keyboard accessible / focus-able by default.
• I've placed the HTML markup for the banner as early as possible in the HTML source order, so users don't have to tab through all of the web page content to reach the banner. The buttons should be the first thing a user encounters on the page after hitting tab.
• I've also added role="region" and aria-label="Cookie Banner" to the <aside> element so that the banner can hopefully be easily searched for and discovered by screen reader users.

Text:

• The banner text meets WCAG AAA standards for color contrast according to Firefox developer tools.

Display considerations:

• The banner should only animate-in when prefers-reduced-motion is set not set to reduce.
• On short view ports under 600px in height (both mobile and desktop), the banner should display static at the top of the page, so it does not obscure web content.
• On taller view ports greater than 600px in height, the banner should display as fixed position at the bottom of the view port.

Describe any areas of concern to which you want the accessibility team to give special attention:

• Might the fixed position banner pose issues to those who find motion discomforting? Would it be better to make the banner static at the top of the page if prefers-reduced-motion is set?
• Do I need to do anything with focus when the banner is opened / closed, if the banner is the first element in the page source order?

Settings page

Please describe the accessibility guidelines you considered and what steps you've taken to address them:

HTML markup:

• I used standard HTML <form> elements and inputs, as well as semantic headings, paragraphs and <details> components for the expandable sections.
• Form input radio toggles have unique ids and associated <label> elements to describe them.
• Submit button is a standard <button> element with type="submit".

Text:

• The form text meets WCAG AAA standards for color contrast according to Firefox developer tools.

Describe any areas of concern to which you want the accessibility team to give special attention:

• Do the native <details> / <summary> elements have enough a11y information built into them, or do i need to add any extra a11y information to the markup?

Comment 3

[James Teh [:Jamie]]

Sorry for the delay on this.

The markup for both the cookie banner and settings page is great. Thanks.

• I've placed the HTML markup for the banner as early as possible in the HTML source order, so users don't have to tab through all of the web page content to reach the banner. The buttons should be the first thing a user encounters on the page after hitting tab.

This isn't necessarily a bad thing, but I'm curious about the intent here. I get the impression you do not want the banner to prevent the user from doing other things; i.e. it is not intended to be modal. Semantically, it isn't modal, which is great. However, if I understand correctly, on larger screens, you display it at the bottom of the viewport, suggesting it isn't necessarily what you want the user to immediately engage with when they see the page. This disparity - having it at the very top from a markup perspective but at the bottom visually - has left me a bit unsure about the intent here: engage immediately or engage later. Can you clarify the intent?

• Do I need to do anything with focus when the banner is opened / closed, if the banner is the first element in the page source order?

In this case, I don't think so because if I understand correctly, you don't want to intrude on the user's engagement with the rest of the page. If the intention was to force the user to engage immediately with the banner, that would be a different story.

• Do the native <details> / <summary> elements have enough a11y information built into them, or do i need to add any extra a11y information to the markup?

Details and summary are sufficient.

NI Anna for a review of the visual aspects.

Comment 4

[Alex Gibson [:agibson]]

Thanks for the questions / comments!

This isn't necessarily a bad thing, but I'm curious about the intent here. I get the impression you do not want the banner to prevent the user from doing other things; i.e. it is not intended to be modal. Semantically, it isn't modal, which is great. However, if I understand correctly, on larger screens, you display it at the bottom of the viewport, suggesting it isn't necessarily what you want the user to immediately engage with when they see the page. This disparity - having it at the very top from a markup perspective but at the bottom visually - has left me a bit unsure about the intent here: engage immediately or engage later. Can you clarify the intent?

I think our intent here is that we want visitors to engage with the banner, but that it also should not be a hard blocker to get to the actual web page content. If people want to ignore it that's fine. But we do want it to be prominent visually, and we also want to make sure it's one of thew first things a screen reader user encounters when opening a page.

Another reason for it being first in source order is that on short viewports (i.e. viewport height is less than 600px), the banner appears static at the top of the page as opposed to fixed position. The aim of this is so that the banner will hopefully not consume all of the available space on smaller devices.

Comment 5

[James Teh [:Jamie]]

So even when it's at the bottom of the viewport (because it's on a large screen), it is "prominent visually" and is one of the first things a sighted user will "encounter" when they see the page? I just want to make sure the experience is effectively equivalent for screen reader users and non-screen reader users alike in terms of engagement, prominence, immediacy, etc. If that's the case, this all looks good to me from a keyboard and screen reader perspective.

I'll leave the visuals to Anna (or someone else on my team if Anna isn't available).

Comment 6

[Alex Gibson [:agibson]]

So even when it's at the bottom of the viewport (because it's on a large screen), it is "prominent visually" and is one of the first things a sighted user will "encounter" when they see the page?

I'd say that's a fair estimation. It does not obscure the top page content, but it is not easy to miss.

Comment 7

[Anna Yeddi [:ayeddi]]

Hi team, and thank you for your patience, :agibson!

On a larger screen, the banner is at the bottom of the screen, covering about a lower quarter of the content. In general, the focus order should follow the reading order of the page, but the reading order could be seen in two ways here:

1. Top-to-bottom, left-to-right (for LTR language like English) - in this case, having the cookie banner as the first in the focus order would be a bug, since the focus appears at the bottom of the page and then, after the banner, it jumps back to the top.
2. Top layer of content first - in this case, the banner would be the first logical place to place the focus on first, because it is visually overlaying the rest of the page content (it even has a small shadow to add to the 3D effect visually). In this case the behavior would not be a bug.

My opinion is that the bahavior as it is now is acceptable for reason of it being an top-layer content. I also think that the second way of thinking may be in the recent years more expected for cookie banners, since there are so many of them and they are expected to overlay the content, be placed at the bottom of the screen on desktop, etc. Plus, there are a limited number of focusable controls (3) on the page and, for instance, skip links are recommended for 3 or more controls that are repeated on each page. So having 3 controls before the content is okay without providing any skip affordance. Also, user of a screen reader could jump to the H1 on the page to skip it all too - thankfully, the heading hierarchy of MoCo website is good.

Visually, both the banner and the settings page are made great - no a11y concerns. I especially was excited to experience a semantic HTML disclosure controls provided with <details>/<summary> elements on the Settings page.

Does the website support High Contrast Mode on Windows? I think everything looked well on HCM, just the banner itself would need a CanvasText border to be visible so it is visually separated from the rest of the content.

Comment 8

[Alex Gibson [:agibson]]

Thanks, Anna!

I agree that your second way of thinking matches how I see the element behaving more closely, since it has become a more common UX over the past few years for cookie banners. If we add more links / controls to the banner (which seems unlikely right now) we'll consider adding a skip link (good call out!). We do not support High Contrast Mode on Windows throughout the website yet, but this is another great consideration for us in the future, so thank you.

Given that there we're no other issues reported here, I'm going to close this out as fixed. But please let me know if there's anything else I need to do in order to finalize the review here.

Thanks again for everyone's help!