Re: SC 1.4.11

>The disagreement comes from how we assume people will interpret the
language for the exception,


Agreed (so in the Understanding documents, let's lead them to the right
​interpretation
)

> ...and who’s responsible for poor default-focus indictors.

Pretty close, but, rather:

...and who’s responsible for poor default-focus indictors
​
when the page author
*has changed any of the browser default​ *
*CSS declaration*
*s​​*
 ​
that impacts the focus indicators
​
(which could include changing the page background color​​, or styling
​​something like a native button​, i.e., like
​
​when
changing the background of the button itself to black, and the impact that
has in Firefox today)​
*. *


*"If you change any of it, you own all of it" *(except when you literally
cannot, due to technical reasons). I don't see that as hard to explain.


JF*​*

On Fri, Jun 22, 2018 at 10:36 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> John Foliot wrote:
>
> > I'm saying we use the precise reading of the exception clause
>
>
>
> OK, going down that route: A state [1] is defined as a characteristic *of
> *the component, therefore is part of the component.
>
>
>
> Therefore you could read that as:
> “the appearance of [*any* aspect of] the component is determined by the
> user agent”.
>
>
>
> Or, you could read that as:
>
> “the appearance of [*that* aspect of] the component is determined by the
> user agent”
>
>
>
>
>
> > I am at a loss as to why we don't want to pursue that approach.
>
>
>
> The literal interpretation (any aspect of a component) will be
> counterproductive as it leads to absurd situations:
>
>    - A change of font, size, or pretty much any CSS attribute (for
>    “appearance”) means the exception doesn’t apply.
>    E.g. a user-agent such as a TV fixes the focus-style but not
>    font-styles, that * is* what the exception was intended for, but it
>    wouldn’t apply.
>
>    - A change to the *background* of the component means it doesn’t apply
>    (e.g. a basic page which has the background and foreground colours set, but
>    not link pseudo-styles).
>
>    - For components (like checkboxes) which have limited styling options,
>    that would lead to either odd design choices (white patches in a form!?),
>    or devs replacing default components with custom ones (impacting other
>    groups).
>
>
>
> I think the “that aspect of” interpretation provides enough flexibility to
> be useful.
>
>
>
> Overall, I think we can agree that:
>
>    - We should advocate for best practice with good contrast (in the
>    understanding doc and elsewhere);
>    - If the author provides the indicator it is in scope.
>    - The use of default focus indicators is not that common.
>
>
>
> The disagreement comes from how we assume people will interpret the
> language for the exception, and who’s responsible for poor default-focus
> indictors.
>
>
>
> Cheers,
>
>
>
> -Alastair
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion