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>
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>
> *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>
> wrote:
>
>> > In fact, *changes*of 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
>
> Advancing the mission of digital accessibility and inclusion
>



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

Advancing the mission of digital accessibility and inclusion