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> 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
"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"