You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello there! The Browser Testing and Tools Working Group is drafting a protocol for automating assistive tech that we're calling AT Driver. Because the user-agent isn't a web browser, it's unclear whether the primitives of the web platform are appropriate for normative language concerning the user interface. We think it makes more sense to write in terms of the accessibility APIs. It seems appealing to reference the definitions maintained here.
For a concrete example, we're currently adding a capability to activate elements. I believe we could do this very concisely if writing in terms of CORE-AAM's "default action" and "focused state". The only problem is that neither of those terms is annotated for external reference today. That's easy to resolve technically, but I'm first interested in learning if CORE-AAM's maintainers consider AT Driver's use case to be in-scope.
Put differently: will it be viable for CORE-AAM to support external normative references in this way?
The text was updated successfully, but these errors were encountered:
Hello there! The Browser Testing and Tools Working Group is drafting a protocol for automating assistive tech that we're calling AT Driver. Because the user-agent isn't a web browser, it's unclear whether the primitives of the web platform are appropriate for normative language concerning the user interface. We think it makes more sense to write in terms of the accessibility APIs. It seems appealing to reference the definitions maintained here.
For a concrete example, we're currently adding a capability to activate elements. I believe we could do this very concisely if writing in terms of CORE-AAM's "default action" and "focused state". The only problem is that neither of those terms is annotated for external reference today. That's easy to resolve technically, but I'm first interested in learning if CORE-AAM's maintainers consider AT Driver's use case to be in-scope.
Put differently: will it be viable for CORE-AAM to support external normative references in this way?
The text was updated successfully, but these errors were encountered: