- From: Hidde de Vries <hidde@w3.org>
- Date: Wed, 25 Sep 2019 20:10:13 +0200
- To: kevin.white@gov.scot
- Cc: wai-eo-editors <wai-eo-editors@w3.org>
- Message-Id: <11E8EC21-A6FB-4932-B0FB-8A3ED354A5C0@w3.org>
Hello Kevin, > Content can be selected by structure - Not sure that 'selected' covers > 'navigation and editing' Have changed to “navigated”, which may be just enough to cover editing, because once you've navigated to a piece of content you want to edit, you can then edit it? > Honours display settings - Not sure that the description adequately covers > the ATAG success criteria. Also, I am not sure that the title makes enough > sense. 'Supports display preferences'? Thanks, changed to “supports display preferences”. > (Accessibility) features documented - Not sure that accessibility needs to > be in parenthesis. The guideline <https://www.w3.org/TR/ATAG20/#gl_a42> covers both accessibility and “all” features, this is why I went for parenthesis, but this may be a > Also, is the idea to provide help documentation? Would > that be closer to title? 'Help documents provided' or 'Support documents > provided' As far as I understand it it can be both to provide help documentation, but also to explain how certain accessibility features work. I interpret this to be as wide as explain it to authoring tool implementors, as well as end users. > Accessible components/plug-ins available - Not sure this is sufficiently > useful or reflects the ATAG SC sufficiently well. Given the later, might it > be better to ask 'Accessible components/plug-ins identifiable'? This is not > the SC but is arguably more useful than just them being available. This one is the most re-interpreted of the list. I will make sure to get some opinions on it from various experts. Re available vs identifiable: the same goes for the 'templates' feature just above it. I agree with your point that available is not useful if not identifiable. For templates, it is one ATAG criterion, for components/plugins (“pre-authored content”) there are two separate ones. What about calling these options: “Accessible templates” and “Accessible components/plug-ins”, without either available or identifiable, and then explain in the description that they'd need to be both available and identifiable? > Number of questions is fine as long as it is clearly communicated and there > is appropriate progress indicator. A, good point. I've created an issue for this so that I don't forget https://github.com/w3c/wai-authoring-tools/issues/9 <https://github.com/w3c/wai-authoring-tools/issues/9> > Revealing the information regarding partial compliance would be essential. > However, that this is being done would need to be clearly communicated to > people submitting their tool Thanks, that's a good idea, have created an issue. https://github.com/w3c/wai-authoring-tools/issues/10 <https://github.com/w3c/wai-authoring-tools/issues/10> > Link to ATAG might be better opening in a new window with appropriate > communication. Would be rubbish if user clicked on that and lost any edits > or progress in form. Yes, I agree, have updated. > Minor: Please describe what your support looks like: “accessible > templates are available, but it is really hard to find them.” -> does > this need a 'for example': Please describe what your support looks like, > for example, “Accessible templates are available, but it is really hard > to find them. Improvements in search will be available in version 11” > I also threw in a suggested addition to the example to highlight that this > might be a good thing to do. Excellent suggestion, have updated this to explicitly say “For example” and add the bit about version 11. > Looking good Thanks, Kevin! Best, Hidde — Hidde de Vries Web Accessibility Specialist Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)
Received on Wednesday, 25 September 2019 18:10:18 UTC