RE: SC 1.4.11

Ok, last one, then I bow out for now.

Interesting math, but it over-simplifies.

Firstly, I still read the state as something that is ‘of’ a component. We state it includes states so that it isn’t just the on-load appearance. We look at the component in it’s various states.

Secondly, we are not necessarily taking the contrast between the component and the state (your (X+Y) + C).
The very first example in the understanding doc increases the thickness of the boundary, so does not contrast at all with the component.

As the wider point, that is why flexibility is needed, we have to be very careful with creating situations where we create three-way contrast requirements (‘cause that doesn’t work).

Have a great weekend,

-Alastair


From: John Foliot <john.foliot@deque.com>
Sent: 22 June 2018 21:44
To: Alastair Campbell <acampbell@nomensa.com>
Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Subject: Re: SC 1.4.11

> John, I had the definitions in front of me whilst writing the previous emails, I know what they say.
​>​
​> It doesn’t help, we used the previous definition of UI component because that was suitable, we added states to say that it applies to states as well (perhaps too liberally).

What I read:

> we used the previous definition of UI component(1) because that was suitable, (BUT or AND) we added states(2) to say that it applies to states as well

(Why? I will suggest because states are not the same as components, and we wanted to be explicit that states where "in play" here as well.)


Let me try this another way:

​​
Requirement:
​ "The visual presentation of the following User Interface Components have a contrast ratio of at least 3:1 against adjacent color(s): Visual information required to identify user interface components and states,"​ ("and" =  "+")

​Exception:​ (reformatted for clarity) "except for

  *   inactive components(*) or
  *   where the appearance of the component(1) is determined by the user agent and not modified by the author(**);

Re-stated:

​
​ IF
 "
​​
X" = UI component(1)
And "
​Y
" = states(2)
And "C" = contrast ratio of at least 3:1
​
​
And "P" = "Pass"​
And "A" = inactive components(*)
And "B" = appearance of the component(1) is determined by the user agent and not modified by the author(**)

​Then:​
(X + Y) + C = P (where X + Y == user interface components and states)

Exceptions:  X +
​A​
=
​P

                     X + B = P


​There is no statement here that says:

                       ​Y + A = P
            Y + B = P
nor
(X + Y) + A = P
(X + Y) + B = P


​> ​
Either we take a view that any change by the author means the exception doesn’t apply, or we apply it more flexibility.

​Exactly​, and my position is that we take the explicit interpretation, as opposed to the implied interpretation.

The exception does not call out states, thus states are not part of the exception (else we would have stated as much in the normative text - which we didn't, by choice or accident, but didn't none-the-less).

Additionally, I will continue to argue that the strict reading of the SC requirement gets us significantly closer to the stated intent and goal of this SC, where-as the more flexible definition will continue to leave some pretty serious gaps.

​JF​


On Fri, Jun 22, 2018 at 2:21 PM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
John, I had the definitions in front of me whilst writing the previous emails, I know what they say.

It doesn’t help, we used the previous definition of UI component because that was suitable, we added states to say that it applies to states as well (perhaps to liberally). The *first* part of the state definition says it is part of the component.

Again, that doesn’t help, it is orthogonal.

Either we take a view that any change by the author means the exception doesn’t apply, or we apply it more flexibility.

-Alastair

Apologies for typos, sent from a mobile.
________________________________
From: John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>
Sent: Friday, June 22, 2018 8:09 pm
To: Alastair Campbell
Cc: GLWAI Guidelines WG org
Subject: Re: SC 1.4.11

> If you agree that the language around ‘nature’ is essentially role, then the definition of state is that it is “of” the component.

That is not what our normative definition states, so
while I ​
respect your opinion here, I still maintain you are reading this wrong.

​"States do not affect the nature of the component,

​...so state is NOT part "of" the component​ -because they do not affect the nature of the component, rather they

(but) represent data associated with the component or user interaction possibilities​

​Components are not defined by their state, and as previously noted in this thread, not all components will have a declared state (inert?)​, so I again reject your attempt to bundle the two together that closely.

If that was true, and our intent, we would have had 1 definition instead of two, and would have one hyperlink to the definition, instead of two:


user interface component

a part of the content that is perceived by users as a single control for a distinct function
NOTE

Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls.
​
state

dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes
States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse.​

On Fri, Jun 22, 2018 at 1:37 PM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
> In fact, changesof state MUST be properly communicated (and perceived) to and by all users. That is exactly why we have role, STATE, and property in ARIA (to accommodate non-sighted users),

Agree.

> therefore I will assert, for sighted users the argument could be made (I'm making it) that state is indeed visually separate i.e. we get differing visual values/cues when state changes, just like we get differing aria-state (audio) values/cues when state changes.

As I think you said before, it doesn’t have to be. It could be visually part of it, around it, even somewhat visually separate. Buit it isn’t necessarily one or the other.

I agree there has to be a dfiference that the person can spot, but it doesn’t help us with the language of the exception and how people interpret that.

If you agree that the language around ‘nature’ is essentially role, then the definition of state is that it is “of” the component.

If you then assert that any change by the author means the exception doesn’t apply, then the list of ‘absurd’ outcomes I put before also apply.

-Alastair



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion