James Craig

> > users expect screen readers to read what’s on screen > I don't think that's such a simple rule. I’m not saying that’s a simple rule. I mentioned that...

Discussed in the editor's call today. We have some concerns about removing this entirely based on history working within accessibility standards groups. However, I'll take a stab at authoring a...

> My opinion is that the safest solution is "no reflection". +1. Among other problems, reflections might cause repaints if selectors refer to them. If that behavior is desirable to...

> This also means that people can continue to use ARIA without being aware of AOM and things will work as expected even if developers use AOM under the hood...

Actually maybe I misunderstood your comment. Clarifying: ```js el.accessibleNode.role = 'treegrid'; el.setAttribute('role', 'grid'); console.log(el.accessibleNode.role); // treegrid console.log(el.getAttribute('role')); // grid ``` I concur with your example above. I thought you were...

I see these as being different from the style cascade. Ultimately having a directly settable API (and eventually a queryable API for computed values) will be more predictable and verifiable....

@alice > Given we can't reflect everything, it seems better not to reflect anything (like value). I agree, but I didn't follow you as far as "ARIA always wins over...

@jakearchibald wrote: > …changes to the attribute are ignored once the value has been altered via the DOM property or by the user My understanding is that "DOM property" refers...

@alice wrote: > It might be simpler to follow the .value pattern and have ARIA changes do nothing once the AccessibleNode has been written to. This is more like what...

The whole API is accessibility specific, so it'd be redundant to use define "accessibility x/y" as a concept. We used the common "offset" terms familiar to web developers so that...