- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Oct 2021 23:27:37 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-highlight-api] Figure out how highlights are exposed to the accessibility tree`, and agreed to the following: * `RESOLVED: Add the new attribute of highlight type which is an enum` * `RESOLVED: add spelling-error, grammar-error, and highlight` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-highlight-api] Figure out how highlights are exposed to the accessibility tree<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6498<br> <BoCupp> https://github.com/w3c/csswg-drafts/issues/6498#issuecomment-930627914<br> <dael> Rossen_: Before we get going, we're starting with 2nd hour of topic. We'll box the first topic to 15 minutes. Right?<br> <dael> astearns: Sure. Not sure if more because topic is complex<br> <dael> BoCupp: I'm seeking maybe a few resolutions<br> <dael> BoCupp: I'll go through what hoping to resolve on and take questions<br> <dael> BoCupp: Issue comment I posted in IRC summerizes proposed API change<br> <Rossen_> q?<br> <dael> BoCupp: Would like to resolve on adding new type attribute to highlight api. Gives symantic meaning that can be used for highlight a11y mappings<br> <tantek> s/symantic/semantic<br> <BoCupp> https://drafts.csswg.org/css-pseudo-4/#highlight-selectors<br> <dael> BoCupp: What to resolve values should include generic highlight on enum that can be used in absense of more applicable value. Any other values should align with pseudo elements named ^<br> <dael> BoCupp: Last part would like to settle on is for L1 of spec with think in addition to generic is spelling-error and grammar-error. Open to additional ones. Right now have selection and target text in spec<br> <dael> BoCupp: Selection is complicated topic. In L1 missing support for pointer events, planned for L2. might defer until then. That's my preference. Additionally selection has semantics that make it more complicated<br> <dael> BoCupp: target-text is more of a question for anyone working on beforeMatch API. Might be good to have discussion on if highlight API can take over that roll<br> <florian> q+<br> <dael> BoCupp: If so might consider expanding enum. Hoping to get as far as we can. I'll take questions on it<br> <Rossen_> q+<br> <Rossen_> ack florian<br> <dael> florian: I think the approach is right. Had been mentioned to use descriptive strings but that has many more problems on translating and how a11y layer can use. Starting with spelling and grammar is good<br> <tantek> q+ to ask if there has been coordination with the Web Editing Working Group, feels like some overlap in scope<br> <dael> florian: Not sure I would limit to what's there. I think what's most important is a11y tree knows how to handle. If the platform knows how to handle we can add those.<br> <dael> florian: You have mentioned find-in-page, I think would make sense to expose even if it's not built in<br> <dael> florian: Agree with general approach. Can explore more values later<br> <dael> BoCupp: Thank you<br> <dael> Rossen_: Question. If we pull back, symantically what you desc makes sense for different types of ranges to be added<br> <dael> Rossen_: From a11y PoV, and this was motivation behind issue, can you explain how these different types of ranges are exposed to a11y?<br> <dael> Rossen_: Specific example: overlapping ranges that are all overlapping one string of text. What is the a11y tree going to look like? Will the highlight ranges have structural changes to a11y tree or simply exposed as property on existing nodes?<br> <Rossen_> ack Rossen<br> <dael> BoCupp: In terms of exposure; chromium a11y tree which translates to multiple platform a11y trees. Those trees have different attribution types. We have different UI constants assigned to range of text. These enums will map to constants in platform-specific way.<br> <dael> BoCupp: On mac see spelling not grammar so we'd map grammar to spelling. If we added find on page and there's no text-match enum we'd map to a generic highlight so the user knows something is highlighted<br> <dael> BoCupp: In chromium the format in tree has start and end ranges over text. Each paired with an enum value that annotates text with meaning. I htink they can overlap. Not 100% sure on overlap, good to followup<br> <dael> BoCupp: Do have priority on highlight interface. If we can't do something for a specific platofrm we can resolve based on priority of highlight. These custom highlights can sort below regular highlights<br> <dael> BoCupp: Does that answer?<br> <florian> q+<br> <dael> Rossen_: Sort of. My worry is we're still exposing something most tree structures are unsuited to deal with. B/c we're allow irregular overlapping. HTML went away from overlapping tags in past and this is allowing. Some worry.<br> <florian> q-<br> <dael> BoCupp: One thing to ease worry even though I don't have specific answer. We do ahve selection, find-on-page, spelling and grammar overlaps. Those exist today and our hope is to mirror native platform<br> <dael> tantek: I like the exploration of the area. Like Rossen_ unsure about implementability. Want to call out difference between delcaritive to style vs and API that could increase impl and privacy challanges.<br> <dael> tantek: find-in-page I wanted to point out browsers distinguish between all instances of text and the current found on text item which the user sees. Slightly different. Not sure if will expose in API<br> <Rossen_> ack tantek<br> <Zakim> tantek, you wanted to ask if there has been coordination with the Web Editing Working Group, feels like some overlap in scope<br> <dael> tantek: That is a privacy hole. giving access to what text is being searched has privacy implications. Not sure how to quantify but want to call it out<br> <dael> BoCupp: Response to that is highlight API does not expose that. It would only be if we have something like beforeMatch event where you would get what user is searching and then highlight you could use. It's not mech to discover what is searched for. Thanks for comments, though. Get distinction on find-on-page<br> <dael> tantek: this does seem to have overlap with web editing group. Is there coordination?<br> <dael> BoCupp: There is. Originally presented there but decided it was better developed in css<br> <dael> tantek: great<br> <dael> fantasai: I think having types of highlights makes sense, esp if can hook into platform APIs. Might be interesting to be able to spec with an extra field that's descriptive and l10n<br> <dael> fantasai: For all cases where we have or expect a highlight it would make sense to define enum up front. As people write code we want them to pick the appropriate enum even if that's not doing something just yet<br> <dael> BoCupp: Good point, thank you<br> <Rossen_> ack fantasai<br> <fantasai> s/and l10n/and allows l10n/<br> <dael> florian: I wouldn't rush to having a string. If we have it too early people would rush to that over enum<br> <dael> fantasai: I think you do that by making string more annoying. Have to put enum and the string and string through dictionary that maps lang tag. I don't think there's a reason not to do unless it would take a while<br> <dael> florian: I think it would take a while. How do you select what translation? UA but that's usually wrong so what do you use<br> <florian> s/that's usually wrong/that's often wrong/<br> <dael> BoCupp: My main concern with free string is that today b/c can't map free string into different platforms those platforms might evolve but in UIA we can't annotate te text.<br> <Rossen_> q?<br> <dael> BoCupp: In absense of author hearing the experience they don't know what to write and some people would write grammar and some would write "you shouldn't have a comma without at least 3 things in a string". How do we put some semantic to it. That was why constrained set of types<br> <dael> fantasai: Makes sense<br> <dael> BoCupp: Point I like is we can add more enums and communicating those semantics is straight forward. I would like to stay away from free string<br> <florian> +1<br> <fantasai> sgtm<br> <dael> Rossen_: I'm seeing +1 on IRC. Let's see if we can take resolutions<br> <dael> Rossen_: Prop: Add the new attribute of highlight type which is an enum<br> <dael> Rossen_: Before we decide on values, opinions or objections to adding?<br> <dael> RESOLVED: Add the new attribute of highlight type which is an enum<br> <dael> Rossen_: Highlight, spelling error, and grammar. Obj to adding those?<br> <dael> heycam: Is there a particular reason to have spellingerror instead of spelling-error?<br> <dael> BoCupp: Propose the hyphen to match the pseudo names<br> <dael> BoCupp: One of the things I said initially is prefer we align with css pseudo in terms of names<br> <dael> Rossen_: Not opposed. We're working on a design principle in TAG that would invalidate this soon, but won't stop now<br> <dael> Rossen_: Prop: add spelling-error, grammar-error, and highlight<br> <dael> RESOLVED: add spelling-error, grammar-error, and highlight<br> <GameMaker> +1 for matching<br> <florian> q+<br> <dael> Rossen_: Thank you for bringing this<br> <dael> florian: Quick question<br> <dael> florian: To make sense this needs to make to a11y tree. Is someone taking action to desc that somewhere? I suspect not in css spec<br> <dael> Rossen_: Suggest we add this to API joint meeting during TPAC<br> <dael> BoCupp: Sounds good<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6498#issuecomment-937321727 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 October 2021 23:27:39 UTC