Re: Focus visible (enh) update

+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



*Can**Adapt* *Solutions Inc.*

Tel:  613-806-9005

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

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> wrote:

> +1
>
> -----Original Message-----
> From: Sailesh Panchang <sailesh.panchang@deque.com>
> Sent: Friday, October 18, 2019 12:47 PM
> To: Alastair Campbell <acampbell@nomensa.com>
> Cc: Detlev Fischer <detlev.fischer@testkreis.de>; 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
>
>