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