There is actually a different standard for authoring apps: the Authoring Tool Accessibility Guidelines (ATAG). This “seemed like the obvious choice”, but the tool doesn’t create “web content” as defined by the WCAG. WCAG defines web content as HTML or PDF or similar, whereas Sanity stores the content as data.
ATAG also doesn’t come with an evaluation methodology like the WCAG Evaluation Method (WCAG-EM), and doesn’t map to VPAT (“a format used to compare accessibility in the US and Europe”). Therefore, they decided to evaluate against WCAG Level A + AA, following WCAG-EM.
Other complications included deciding the scope of the audit. For a highly customisable application that can accept lots of plugins, how far do you evaluate? They opted for a minimally customised and representative site that they use for client demonstrations.
The end result was an audit covering 50 Success Criteria, of which 36 were satisfied. The remaining had issues identified, which is a “list of opportunities to improve accessibility in the Studio”.
The article ends with a link to Collaboration Tool Accessibility User Requirements, which is a W3C working draft of guidelines for making real time collaboration more accessible.
Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.