Review Request for CSS Custom Highlight API Module Level 1

Hi APA Working Group,

The CSSWG's Custom Highlight API Module Level 1 was recently published as a FPWD, and as one of its editors, I thought this was a good time to let you know of its existence and invite initial review.

  https://www.w3.org/TR/css-highlight-api-1/

The Custom Highlight API extends the concept of highlight pseudo-elements (see CSS Pseudo-Elements 4 ยง3 Highlight Pseudo-elements) by providing a way for web developers to style the text of arbitrary Range objects, rather than being limited to the user agent defined ::selection, ::inactive-selection, ::spelling-error, and ::grammar-error. This is useful in a variety of scenarios, including editing frameworks that wish to implement their own selection, find-on-page over virtualized documents, multiple selection to represent online collaboration, or spellchecking frameworks.

The Custom Highlight API provides a programmatic way of adding and removing highlights that do not affect the underlying DOM structure, but instead applies styles to text based on range objects, accessed via the ::highlight() pseudo element.

These "custom" highlights are currently thought not to introduce any accessibility considerations beyond what is already present in CSS in general, and in the non-custom highlights that this technology builds upon in particular, but the CSSWG would be interested to know if you can spot something we missed.

Please raise any issues in the csswg GitHub repo:
    
   https://github.com/w3c/csswg-drafts/issues

If you think this specification has nothing of interest for your group, please let us know. Otherwise, we will request review again when we get close to CR, and if anything major changes before then.

= FAST Checklist =

## If technology allows visual rendering of content

The technology does not create content that can be rendered visually (or otherwise), it affects *how* visual renderings of otherwise defined content looks like. The questions in this section are therefore not directly applicable. The answer for all of them is that this technology does not change what is generally true of HTML (or other markup languages) styled with CSS.

## If technology provides author control over color

# There is a mechanism for users to override colors of text and user interface components.

Yes. CSS provides for that in general, and this feature is no exception.

# There is a feature for authors to define semantically available "color classes" that users can easily map to custom colors, and give preference to this vs. coloring objects individually.

As far as I understand the question, yes. CSS provides for that in general, and this feature is no exception.

# There is a feature for users to choose color schemata that work for them.
# The foreground and background color of an object can be reported to the user via AT.
# There are ways to set foreground and background colors separately for all objects.

Yes. CSS provides for that in general, and this feature is no exception.

# Compositing rules for foreground and background colors are well defined.

Yes. Highlights, whether custom (as defined in this specification) or built-in (as defined in CSS Pseudo-Elements 4, upon which this specification builds) work a little differently from the rest of CSS due to the fact that they do not abide by the tree structure of the DOM, but care has been taken in CSS Pseudo-Elements 4 to make sure this was well defined and work well to give usable and predictable contrast. This specification reuses this mechanism.

## If technology provides features to accept user input

It does not.

## If technology provides user interaction features

At this stage, it does not. It is anticipated that the specification will be extended to allow events to be captured when the user attempts to interact with the highlights, in order to let authors react to these interactions, but this mechanism has not yet been defined.

## If technology defines document semantics

In a strict sense, it does not, and the questions in this section do not meaningfully apply.

However, the technology allows authors to change the appearance of certain "highlighted" parts of the document, and based on this users may infer certain semantics. This change in appearance is achieved through (a restricted subset of) the usual CSS facilities, which are themselves conveyed to users of assistive technologies. Non-visual users therefore have as much of a chance to infer any implied semantics as visual users do.

## If technology provides time-based visual media

It does not.

## If technology provides audio

It does not.

## If technology allows time limits

It does not.

## If technology allows text content

It does not. The technology provides for styling of content, it does not provide content itself.

## If technology creates objects that don't have an inherent text representation

It does not.

## If technology provides content fallback mechanisms, whether text or other formats

It does not. The technology provides for styling of content, it does not provide content itself.

## If technology provides visual graphics

It does not. The technology provides for styling of content, it does not provide content itself.

## If technology provides internationalization support

The technology is language/locale agnostic.

## If technology defines accessible alternative features

It does not.

## If technology provides content directly for end-users

The technology provides for styling of content, it does not provide content itself.

## If technology defines an API
# If the API can be used for structured content, it provides features to represent all aspects of the content including hidden accessibility features.

Not certain how this statement applies to the technology at hand. I believe the fact that The technology provides for styling of content rather than content itself makes this point irrelevant, but I may be missing something.

# If the API relies on user agents to generate a user interface, the specification provides guidance about accessibility requirements needed to enable full interaction with the API.

It does not.

## If technology defines a transmission protocol

It does not.

Received on Tuesday, 8 December 2020 07:49:08 UTC