WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: 2.1: Testing 1.4.13 With a Screen Reader

for

From: Mallory
Date: Mar 2, 2019 5:50AM

Due very much to some of your points, I have these in mind when building/recommending stuff:

1. I assume plain text content appearing on hover/focus would attempt to follow something like the tooltip pattern-- meaning it gets read out when the trigger gets focus; I dislike this for anything not super short/succinct, as it's getting announced via an aria-describedby so I can't check spelling and whatnot.

1a. Anything long-ish or with funky characters (for example tooltips showing keyboard shortcut keys), I like the trigger accept a dedicated click (and expose an expanded/collapsed state) to persist the new content (hover can still hover if the client's users tend to expect that) instead of auto-reading-content-with-describedby.

2. For content with focusables-only, it gets weird: while moving forward, the new content would be as if it were page content after the trigger (as focus on new-content focusables should persist the new content entirely, similar to fpcus moving to submenu dropdowns). However if the user isn't informed that this is added pop-uppy content, then when they back-track that new content won't exist until they hit the trigger again. You get this weirdness in the Gutenberg editor for example.
Whether the user is moving forward with focus or not in theory shouldn't matter: if focus doesn't move with the virt cursor, it remains on the trigger and content remains onscreen. If focus does move with the virt cursor, as it goes into the new-content focusables, the new content should remain persistent (same as persistent for hover cursor).

The current big problem with this is that developers are not putting the new content in the DOM order. These popups and things are often stuffed into the top or bottom of the document, and positioned onscreen using CSS. When auditing, we have filed issues for this: either insert that content into the correct DOM order OR manage focus (this again goes back to 1a where a click must trigger the new stuff. Causes all sorts of problems with voiceOver but then, voiceOver has trouble with JS-managed focus anyway).

For mixed focusables and plain text (like a small non-modal popup with a "got it!" link or voting buttons or whatnot), I like going back to 1a (let hover do hovery things if you want, but make the trigger an aria-expandable clickable where click persists the content).

Folks may find a current discussion on Github interesting (React community): https://github.com/reactjs/rfcs/issues/104

_mallory

On Fri, Mar 1, 2019, at 7:10 PM, Jim Homme wrote:
> Hi,
> As I think about how a screen reader operates, I'm wondering if I am
> missing something by thinking doing this may be difficult. Does anyone
> have any thoughts on this? Here is what I'm thinking.
>
> You are on a web page. As you know, assuming everything works right,
> your screen reader puts focus on a control when it sees it. Here is
> what I'm thinking about what would happen.
>
>
> * The content would appear, but the screen reader would not speak
> it, and the user would not know it appeared.
> * The content would appear and speak, but as soon as the user moves
> to try and find it, the screen reader drags focus away from the
> control, and the content disappears.
> * There could be a piece of content on a page that has tab order,
> but is not a control. The screen reader would not drag focus there, and
> even though the developer intends for content to appear when focus
> lands there, that does not happen because the screen reader is using
> arrows to read and not using TAB.
>
> What am I missing?
>
> Jim
> ==========
> Jim Homme
> Digital Accessibility
> Bender Consulting Services
> 412-787-8567
> https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
>
> > > > >