Platform software must offer documented platform accessibility services for every user interface concept named in the object-level clauses 11.5.2.5 through 11.5.2.17 that it supports (11.5.2.1; V3.2.1's separate documentation clause is merged into it, so 11.5.2.2 is void). Open functionality should use those services, falling back on other documented platform services where they are not enough (11.5.2.3, a recommendation). Assistive technology must itself use the documented services for the same concepts (11.5.2.4). Through those services, open functionality must expose to assistive technology: the role, name, description, states and on-screen boundary of each element (5); for data table cells, their row and column plus any headers (6); current values and the limits of a range (7); which element labels which (8); hierarchy between parent and child elements (9); text content, its attributes and its boundaries (10); the actions an element offers (11). It must also let assistive technology run those actions where security allows (12), follow focus, caret and selection (13) and change them where the user could (14), be told when the exposed attributes change (15), and alter states, properties, values and text that a user could alter without assistive technology, using the platform's input methods for values and text (16, 17). The numbers in brackets are the 11.5.2 sub-clauses.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.