RE: appearance:none, UA stylesheets, and the like

The effect of appearance:none is that the widget is not rendered using the operating system’s “native” style. This shouldn’t affect what is disclosed to assistive technologies, as the role/states/properties are unchanged. However, if it could be implemented in such a way that it would inadvertently alter what is disclosed to AT, perhaps a note should be added to a suitable specification to clarify the intent. I suspect it’s a non-issue, but we need to be sure.

https://drafts.csswg.org/css-ui-4/#appearance-switching


From: John Foliot <john.foliot@deque.com>
Sent: Wednesday, August 26, 2020 11:48 AM
To: Florian Rivoal <florian@rivoal.net>
Cc: Greg Whitworth <gwhitworth@salesforce.com>; Cameron McCormack <cam@mcc.id.au>; Elika Etemad <fantasai@inkedblade.net>; www-archive@w3.org; W3C WAI Accessible Platform Architectures <public-apa@w3.org>
Subject: Re: appearance:none, UA stylesheets, and the like

Lurker question.

What is the impact of appearance:none on Assistive Technology? While CSS generally has no impact on screen readers, "display:none" *IS* respected by those tools. Content marked display:none is not voiced aloud by screen readers, and I have a concern that we may see a similar pattern here, where the semantic of the control would be lost due to a similar CSS construct.

Not sure if this came up, but curious to know if this concern has been raised.

JF

On Tue, Aug 18, 2020 at 7:58 PM Florian Rivoal <florian@rivoal.net<mailto:florian@rivoal.net>> wrote:
Hi Greg and heycam,
(CCing fantasai)

I had a brief follow up conversation with fantasai after the open UI call, where we did manage to resolve some of our philosophical differences exposed during the call (fantasai, correct me if anything I'm saying here is inaccurate), and I think there's a nice way forward from there.

First, there's no disagreement at all that providing authors with the ability to write parts of their own controls and then telling the browser to hook them up correctly and inject the desired behaviors and relations is desirable. That's all good. What I am talking about the case where we're not doing that, and where authors are trying to some degree or other to restyle / influence the look and feel of existing html control elements.

When we have a button, or a checkbox, or one of these controls that has a fundamentally simple structure, fantasai is fine with having the appearance:none structure be made explicit, and to have a default UA style be defined.

However, it gets trickier for things like a select, or an type=range input, or other complex controls. With the select, the closed state is somewhat buttony, and so here too, having its appearance:none mode have a defined structure and a defined UA style would be fine. But what about the open state? She argues that that part should remain native-ish, and the browser should retain the freedom to do all sorts of UI adaptions to match devices/environment/window size/etc. To the extend we want to give authors control over what the open state looks like, it should be through fuzzy hints like accent color and possible other things along these lines, not by making appearance:none flatten the entire structure of the complex component into the lowest common denominator.

There are actually open issues going in that direction in the current appearance spec, I think we can find a reasonable middle ground there.

I need to define a few terms here to express what I want to say:

* a component or of part of a component is *influenceable* if it can respond to things like accent-color, or color-scheme, or other future properties that give a fuzzy hint at what the other want, while leaving the precise way to interpret these propeties' effect up to the UA. Any and all hints can be ignored (although honoring then when practical is desirable). It may be reasonable to allow some traditional properties like color or font-family to be useable as hints by influenceable controls, but layouty things like padding or flex should not, as you cannot make any assumption about the structure of such controls.

* a component or part of a component is *styleable* when the way is looks is precisely expressed using css-properties onto a DOM structure of some kind. We can distinguish:
  * "shallowly styleable": the outer parts of a control are styleable, but some of its sub-components are not, and are merely influenceable.
  * "fully styleable": the entirety of a control, recursively to any sub-component.

Under appearance:auto, the UA can make controls influenceable.

appearance:none makes controls styleable. It doesn't necessarily have to make them fully styleable though, and some of them could be shallowly styleable.

What I think we need to do is:
* define which controls are fully styleable, and for those that are, what the underlying DOM structure is (may be nothing more than a div, may be more, but we need to say), and what the UA stylesheet for this structure is
* for those that are only shallowly styleable, define what the underlying DOM structure of the styleable parts are, how the unstyleable sub-components fit into that, and what the UA stylesheet for the styleable parts are. It's fine to say that some subcomponents aren't styleable, but for what is styleable, the complete UA stylesheet should be defined.

I think it's important to agree on what is styleable and what is not, and when they are, how they work. For example, with appearance:none applied, it would be bad if the magnifying class icon of a type=search input, or the downwards pointing arrow of a closed select, are done via css on the ::after in some browsers, via css on some kind of ::search-icon or ::select-button in some other browsers, and done via native components in yet another browsers. Same logic for the checkmark in a checkbox. To me, all this should be styleable, and therefore have a known DOM structure with a standardized UA stylesheet.

On the other hand, I don't have a strong view that something like the track and knob of a type=range input need to be styleable. Maybe they can be some kind of influenceable replaced elements slotted at a known place within the structure. But if so, it would be good to decide on whether they are 2 replaced elements whose placement is done via CSS on a known DOM structure, or if the combination of the track and knob is one styleable replacement element thingy.

The lower bound of what needs to be styleable (and therefore fully specified, including DOM structure and UA stylesheet) is set by compat constraints. We might want to make more than that be styleable, but we need at least that.

Maybe we also need an additional notion, to describe components whose appearance within the page is fully styleable, but which, when activated, pop up some influencable but not styleable overlay or full-screen dialog, like a clock face to pick the time, or a windowed color picker, or what have you. Or maybe all controls should always have the right to do that, and that needs not be observable to authors as such things are out-of-flow / out-of-page, and don't influence layout.

Whether select is one of those, or a shallowly styleable thing, or a fully styleable thing is an interesting question onto its own.

—Florian
PS: This mail feels like it would be even longer if I needed to post it to some mailing list or github issue that doesn't have the context of the conf-call we just had, but nothing in it is meant to be confidential, so I've cced www-archive to make it linkable, and you may repost this to whatever other place feels appropriate.


--
​John Foliot | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdeque.com%2F&data=02%7C01%7Cjjwhite%40ets.org%7Cec020b96e6b54d3bac2508d849d79211%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C637340537503798156&sdata=uRSo%2FWuPubG3OC29YokoOlMyD4LKj72CnT817MFdhxM%3D&reserved=0>
"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"



________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________