- From: Dan Clark via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Sep 2021 17:04:32 +0000
- To: public-css-archive@w3.org
Another thing I'll add here is that an advantage of an enum over a string is that when OSs have some first-class representation for any of the use cases in the enum, user agents could plug into them directly. For example, custom spell check implementations using Highlight API could be represented to accessibility tools in the exact same way as ranges marked by the native spell-checker. In UIA this might [AnnotationType_SpellingError](https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-annotation-type-identifiers), or [NSAccessibilityMarkedMisspelledTextAttribute](https://developer.apple.com/documentation/appkit/nsaccessibilitymarkedmisspelledtextattribute) on Mac. This would be a more consistent experience for AT users and would save the author the trouble of localizing a "spelling error" string. It's also feasible that in the future ATs could become more powerful and offer first-class representations of more of these use cases, and it would be great if authors can provide metadata that provides a better experience in those cases. If needed, in an L2 of the spec a string attribute could be added to `Highlight` for use cases that fall outside of those we've expressed in the enum. But for use cases that become common and have support in ATs across OSs, it seems more powerful to enable these as additions to the enum. Allowing arbitrary strings could miss opportunities to line up with things that OSs recognize. -- GitHub Notification of comment by dandclark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6498#issuecomment-925115621 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 September 2021 17:04:34 UTC