W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2021

Re: [csswg-drafts] [css-highlight-api] Figure out how highlights are exposed to the accessibility tree (#6498)

From: Dan Clark via GitHub <sysbot+gh@w3.org>
Date: Mon, 30 Aug 2021 22:44:26 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-908755397-1630363465-sysbot+gh@w3.org>
I agree with @dlibby that for the question of how to expose the highlight ranges to ATs we should be able to follow the lead of how ::spelling-error and ::grammar-error are exposed in Chromium, at least in part.

For expressing the semantics of the highlight ranges, the most flexible option seems to be to add a `title` string attribute to `Highlight`, which would be exposed to ATs. However, as pointed out in https://github.com/w3c/csswg-drafts/issues/4601#issuecomment-806426095, these strings wouldn't be localized. This approach also depends on the author to provide a string with the correct level of descriptiveness.

An alternative I'd like to consider is adding an enum to `Highlight` that captures the common use cases we expect for this API. These would be exposed as appropriate in different accessibility platforms, e.g. in UIA the most closely matching [`AnnotationType`](https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-annotation-type-identifiers) would be used.

enum HighlightType {
 "spellingerror", // Exposed to ATs in the same way as ::spelling-error
 "grammarerror", // Exposed to ATs in the same way as ::grammar-error
 "textmatch", // e.g. for custom find-on-page results
// ...and any others for the common use cases we can think of.

interface Highlight {
  constructor(AbstractRange... initialRanges);
  attribute long priority;
  attribute HighlightType type; // Exposed to ATs. Default is "highlight".

The benefit of this is that we're not relying on author-specified strings, so it's easier for developers and it solves the issue of localization. An enumerated set of types could also be easier to expose to ATs.

The disadvantage is that use cases we don't anticipate won't have any good choices so authors will have to fall back to the generic "highlight". I don't think we'd be locked into the initial set of HighlightTypes though; we could probably add more if additional common uses cases arise.

GitHub Notification of comment by dandclark
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6498#issuecomment-908755397 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 30 August 2021 22:44:28 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:43 UTC