RE: Focus visible (enh) update

David, take a look at something like Google sheets when you move focus around in the sheet with arrows without going into edit mode – it may not be trivial to solve as there may not be programmatic focus on screen.   Solving issues for each site is tricky especially with how Stylus works at the same level as the page’s style not as a user style sheet.  There are complex rules for precedence.  The best place for this to be solved is actually by the user agents and perhaps with a new property that allows a visible focused control to be marked as focused even if it doesn’t have the actual keyboard focus.

Many of these online office apps like Google docs tend to use ARIA and hacky ways to communicate with screen readers and lack real focus – but instead have a faux focus that screen readers see off-screen and then they apply a visible focus on top of the screen for sighted people – but there isn’t a way for a Stylus user to know visible but non-keyboard focus.  Think canvas with fallback content and drawn focus rings.

Jonathan

From: David MacDonald <david100@sympatico.ca>
Sent: Friday, October 18, 2019 2:28 PM
To: Newton, Brooks (TR Product) <Brooks.Newton@thomsonreuters.com>
Cc: Sailesh Panchang <sailesh.panchang@deque.com>; Alastair Campbell <acampbell@nomensa.com>; Detlev Fischer <detlev.fischer@testkreis.de>; w3c-wai-gl@w3.org
Subject: Re: Focus visible (enh) update

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

+1

Although it feels a bit awkward to require hundreds of thousands of developers and designers to tweak websites, when a plugin like stylus on the user side seems to do quite well. But I can live with the SC understanding that lots of people aren't technical enough to use that type of AT yet, and there are some limits to plugins.


Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613-806-9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://www.can-adapt.com/>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>


On Fri, Oct 18, 2019 at 2:02 PM Newton, Brooks (TR Product) <Brooks.Newton@thomsonreuters.com<mailto:Brooks.Newton@thomsonreuters.com>> wrote:
+1

-----Original Message-----
From: Sailesh Panchang <sailesh.panchang@deque.com<mailto:sailesh.panchang@deque.com>>
Sent: Friday, October 18, 2019 12:47 PM
To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Cc: Detlev Fischer <detlev.fischer@testkreis.de<mailto:detlev.fischer@testkreis.de>>; w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>
Subject: Re: Focus visible (enh) update

Alastair,
Reference your statements this morning:
<start>
In most cases if you are using a complete outline around the component it makes no difference at all, and you’d automatically fulfil it.
The one area I found that might surprise people is that the default (in Firefox) 1px dotted outline would not pass in most cases.
It is not a new thing that browser default indicators would fail, on the Mac the default indicators for some browsers fail the contrast requirement already.
</end>
Given this, is it reasonable to  ask designers and developers around
the world to  include markup / styling that will   correct issues that
should really be addressed by the browser?
Maybe browser makers should be urged to  improve the default focus indicator area and contrast issues that are noted as accessibility concerns.
And then if developers  override those  introducing accessibility barriers, those should be flagged to their attention as content-accessibility problems: much like when developers suppress default focus indicators.
Another example: the HTML5 placeholder attribute when first implemented posed contrast problems. True, developers were urged to remedy this but it was taken up with browser makers who fixed it at their end.
Best wishes,
--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon, VA 20170
Mobile: 571-344-1765