Keyboard focus text in Experience Builder

[andrewdfahey]

I'm trying to better understand how Experience Builder text widgets work as they relate to keyboard navigation and screen readers. Using this example application, a keyboard and screen reader test cannot focus on the title, subtitle, or the text above the filters in the sidebar which may all be strikes against WCAG 2.1.1 on keyboard navigation at the least. I'm mostly ignorant of accessibility testing and the only extension my organization can use for accessibility testing is SiteImprove. Between those two limitations, I'm curious for some insight on how I can rectify the issue that arises with these sorts of text widgets cases. SiteImprove always seems to maintain a keyboard error against WCAG 2.1.1 on keyboard navigation is present which I can validate by not being able to focus on the text at all.

Things I've checked:

• The text in the application right now is in a flow row widget
• Putting it in other layout widgets returns the same error
• Leaving it as bare text widgets not inserted into a layout widget returns the same error
• Having it in the designated header or not does not affect the error
• I've found at least one proposed solution to insert text into a card or section widget, but that can't really fit with an application title as a solution
• I tried turning off and on the A11y setting at the bottom right of the edit view and shifting the flow row widget to re-autocalculate the widget order only to get the same error

Note the attached image shows that the flow row is another instance of the same issue, but I'm more concerned about the other three strikes which are from the text I've described since I can always just remove the flow row while the text is necessary.

[CatherineWendland]

I'm not sure why Siteimprove is saying the title is not keyboard accessible. I tried using a screen reader (NVDA) on your app and was able to get it to read the title and text in the header using the arrow keys.

The Siteimprove error message is pretty confusing - I'm not a professional tester either, but I'm trying to learn for our organization, so maybe there's something I'm not getting either.

The error says there's a "scrollable section" that isn't accessible by keyboard. Maybe because the text box could technically be scrollable (even though you don't have enough text there to require scrolling) it shows as an error through the automated checks.

I also tried resizing the window and increasing the zoom level, and was pleased to find the header wrapped the text nicely and seemed to perform well at 200%. Your app seems like it's pretty well-made accessibility-wise. We aren't going to be able to get a totally accessible app at this point, and it looks like you've done as good as you can.

@Esri - I wonder if the siteimprove error message is more about the underlying code that is triggering this error. If the code can be adjusted it might not throw off the error.

[andrewdfahey]

Hi @CatherineWendland thanks for looking at it with another checker since it's a bit of a roadblock internally that we can only use SiteImprove on external web pages. Conformance checker software/extensions seem to pick up on different things which adds to the confusion at times. I was going to reference another post I saw about Instant Apps headers being weird in WAVE, but looking again I see it was yours!

I agree the error was strange when it was talking about a scrollable element, and I should have highlighted that language. What confuses me more with the wording of that error is that it suggests the flow row and text is something the keyboard should get to when I tab through the application so that I can scroll even though there's technically nothing to scroll through. I'm glad you got a screen reader to pick up on it at least.

The 200% error I get too throws me off in terms of conformance since the text is massive being title and header text which makes 200% of that gargantuan. However, SiteImprove seems to pick up on the fact that it can't be sized to 200% because the app has to reduce the text size to fit, so I can't really tell if that is still a breach exactly. That is likely more of an internal discussion though I think regarding our policies. Thanks for looking at it!