NVDA doesn't read consent banner on page load

[paruchurisilpa]

Reproduction Steps

1.Go to http://192.168.1.77:7080/sport/football/55699252 2.Click on down arrow to navigate to the consent banner 3.It doesn't appear to read the consent banner

Windows 10 NVDA version 2020.3 Browser ff

Context

When accessing our pages in Firefox, using the screenreader NVDA, the consent banner loads in after NVDA begins to interact with the accessibility tree. This means that the banner is not announced as part of the page contents, and the NVDA cursor starts at the brand logo in the navigation (missing the consent banner out).

A11y Acceptance criteria

• If privacy banner shows, h2 should capture focus and be announced upon the banner loading in client-side
• Clicking OK button should close banner and show cookie banner
• When cookie shows, h2 should capture focus and be announced upon the banner loading in client-side
• Upon selecting Accept/Reject, the user's focus should move to the brand link at the top of the page
• There should be no focus outline on the h2 when focused.
• Users should be able to navigate out of the consent banner once focus is captured.

This issue requires a dev a11y swarm only around this specific bug, this should include testing with keyboard only navigating via the tab key, and should also be tested with all our supported screen readers

[andrewscfc]

Looking into this issue I took a snapshot of the contents of the header section of a story page:

header element html from Sport page

```html

We've updated our Privacy and Cookies Policy

We've made some important changes to our Privacy and Cookies Policy and we want you to know what this means for you and your data.

• OK
• Find out what's changed

BBC SportSkip to content

Sections

• Home
• Football
• Formula 1
• Cricket
• Rugby U
• Rugby L
• Tennis
• Golf
• Athletics

• Home
• Football
• Formula 1
• Cricket
• Rugby U
• Rugby L
• Tennis
• Golf
• Athletics

```

The consent banner currently sits within a header element labelled with the banner role mdn defining the banner role as:

A banner role represents general and informative content frequently placed at the beginning of the page. This usually includes a logo, company name, search icon, photo related to the page, or slogan.

I'm not sure a cookie banner fits under that description particularly as the banner is no longer visibly at the top of the page and is pinned to the bottom.

Doing a little reading I'd suggest the consent banner should be have the dialog role mdn describing it as:

The dialog role is used to mark up an HTML based application dialog or window that separates content or UI from the rest of the web application or page. Dialogs are generally placed on top of the rest of the page content using an overlay. Dialogs can be either non-modal (it's still possible to interact with content outside of the dialog) or modal (only the content in the dialog can be interacted with).

The banner is overlayed over the content and pinned to the bottom of the page so seems to fit this definition pretty neatly. I am hoping that screen readers such as NVDA may be more likely to read the content in markd up in this way? I'd be interested to hear your thoughts @greenc05 ?

[greenc05]

Is this a side note to the issue? Not sure how it would fix it?

Aside from that, a modal is something we have discussed at lengh and it's not technically possible at this time (because we are using the same code for when this is non modal)

In my opinion this does fit the descrition (this is general and informative content that is frequendlty placed at the beginning of the page) so should be in the header landmark.

[andrewscfc]

Is this a side note to the issue? Not sure how it would fix it?

I'm suggesting that if it was marked up more accurately (debateable I appreciate), the screen reader may be more likely to read it out. Aside from that I have no specific ideas how to go about fixing this other than marking it up in a different way?

[andrewscfc]

Aside from that, a modal is something we have discussed at lengh and it's not technically possible at this time (because we are using the same code for when this is non modal)

The dialog role suggests it is applicable to both modal and non-modal dialogs, our banner itself being non-modal.

[greenc05]

As we've already established that this works fine in Storybook. Next I would recommend that you copy and paste the raw HTLM from the page in question that has the bug and test this with NVDA. Does the bug exist?

[greenc05]

@andrewscfc You may wish to read the GEL guide on Action dialogs (modals) https://bbc.github.io/gel/components/action-dialogs/

[greenc05]

You could also use the 'Accessiblity' tab in the inspector to try and debug on the page in question

[andrewscfc]

As we've already established that this works fine in Storybook. Next I would recommend that you copy and paste the raw HTLM from the page in question that has the bug and test this with NVDA. Does the bug exist?

The html included in my first comment reads out in nvda fine, I just opened this file on its own in firefox story-banner.html.zip

I would imagine though the bug relates to the context it is used in, i.e. the full page.

[greenc05]

Could you try that with the full page HTML?

[andrewscfc]

You could also use the 'Accessiblity' tab in the inspector to try and debug on the page in question

hmm this looks all right to my untrained eye? Can't see why nvda wouldn't read it first

[andrewscfc]

Could you try that with the full page HTML?

Great suggestion, I did this by viewing the page source and the consent banner is absent when the page first loads, clientside js deciding to show it based on a cookies; I wonder if NVDA builds the structure of the document before the clientside js has chance to run?

With this new insight, I think this adds weight to marking this up as a dialog as it is dynamic content shown based on the user's cookies. In the case of the privacy banner the information is informative and can be optionally dismissed, in the case of the cookie banner, the banner must be acted upon or left to display on each visit. In both cases though, the banner is non-modal, I don't know how that fits into the gel guidelines?

[greenc05]

A note on the way NVDA works: “On the modern, highly dynamic web, there’s not really a reliable way to determine when a page has finished loading. We used to wait until all resources finished loading before enabling browse mode, but on really large or slow loading pages or pages with a lot of images, stylesheets, JavaScript, etc., this can mean the user has to wait an unreasonable amount of time before they can interact with the document. In some cases, it means they can never interact at all; some pages in modern web apps always report as “busy”. In contrast, a sighted user sees content as it arrives. Thus, we made the decision several years ago to just enable browse mode and say all as soon as the document got focus (which is usually when the browser thinks it has enough content to do something useful).”

Seems like NVDA just hooks in really early in loading and there’s not much we can do about it. We can use a react hook to focus the user into the banner once it loads, but on poor connections or devices with poor performance running JS that might mean that they have focus stolen once they’ve already started browsing (for all users).