Compatibility with screen readers

[slavanga]

I just found this comment about what input on a11yproject.com:

Consider this third solution as a last resort. Some browser/screen reader combinations fire mouse events, which could cause outlines to disappear while using this method.

Can someone confirm or deny if what input is working correctly with screen readers?

[ten1seven]

Hi @slavanga, thanks for sending this article! Like it mentions, What Input doesn't set styles itself -- it sets an attribute on the body, leaving styling up to the individual author. In that sense, the script itself doesn't violate any issues with what events a screen reader fires.

However, the suggested usage for styling...

/**
 * set a default :focus style
 */
a:focus {
  outline: 3px dotted #06c;
}

/*
 * remove :focus style via What Input using progressive enhancement
 * so :focus isn't left broken if JavaScript fails
 */
[data-whatinput="mouse"] a:focus,
[data-whatinput="touch"] a:focus {
  outline: none;
}

...could cause the issue noted in the article. I haven't done specific testing with screen readers and I wish the article had pointed out what combinations caused issues. Since the choice is in your hands, you could leave default styling in place and enhance keyboard focus styles alone, like:

[data-whatinput="keyboard"] *:focus {
  outline: 3px dotted #06c;
}

What Input was born in the agency world where tight design control includes the common request for :focus { outline: none; }.The script is a response to providing that control for designers while maintaining accessibility. There can be a tradeoff. I wrote a post on this topic. If you have time I invite you to check it out and welcome your comments.

[slavanga]

@ten1seven thank you for the explanation.

Your post about accessibility in agencies hits the nail on the head. I'm ok with a little tradeoff and using What Input is still better than just removing outlines.

It would be interesting to know what problems (if there are any) the use of What Input can cause for screen readers. Honestly, I have no clue how to test this myself so I thought someone with more experience could take a look and report back.

[ten1seven]

I wasn't aware of specific issues until you brought the a11yproject.com article to my attention. I'm going to look into it and leave this issue open and report back with what I find.

[ten1seven]

Okay, I found this article by the always awesome Paciello Group and was able to test and verify the issue with a simple test page.

I just pushed version 1.2.4 which adds keyup as a keyboard detection method. In testing, the order of fired events when replicating the issue looks like:

Since keyup is the last event fired, this overwrites the detected mouse events without doing anything too heavy-handed to try to fake out screen readers. Unfortunately, based on my testing, I found that until the keys are released the mouse detection persists -- so during the act of clicking a control the styles might swap out if you have different styles for mouse and keyboard. However they quickly switch back when the keys are released.

I'm pretty happy with this solution as it doesn't do anything too convoluted and maintains the primary intent of the script.

[slavanga]

This definitely makes What Input more bulletproof. Thank you for taking a look!

[ten1seven]

Great! I'm closing this issue then.