Re: [wbs] response to 'Authoring Tools List: first draft review survey'

Hi Brent,

Thanks for your feedback! 


> In "Works with Keyboard": Typo - "There should be [[note]] keyboard
> traps."

Oops, fixed.

> In "Content Searchable": Clarification of content - Try replacing with
> something like, "Users can search in text content, results are focused when
> shown. If there are no matches, result is shown. Search result mechanism is
> two-way (backwards and forwards)."

Changed to: 

Users can search in text content, results are focused when shown. If there are no matches, this is indicated. User can search in two directions (backwards and forwards). 

> In "Honours display settings" use American spelling of "Honors"

Ok, updated.

> In "Previews are accessible": Needs more detail or clarification - Not
> being an ATAG expert, this one is not as intuitive to understand as the
> others. Needs some work, maybe by ATAG experienced reviewers.

Have updated to be:

When the tool shows a preview of the content, that preview is at least as accessible as in current browsers and other user agents. 

Agreed it may need more work still, when ATAG experts look at it.

> In "Checks accessibility automatically": Small edit - "Has built-in checks
> for common accessibility problems that identifies [[issues]] like missing
> alt text."

Have updated to be: 

Has built-in checks for common accessibility problems, for example a check to identify missing alt text. 

> Comments: 
> If we do list all of these "features" in the details drop down, then I also
> think we are going to need a glossary for each of the features. Some who
> are searching through these details won't know what it means just from the
> name of the feature.

Great point. I think this tool can not just help people find authoring tools, it can also help people understand what authoring tool accessibility looks like.

I feel the Selecting Authoring Tools page would be the ideal candidate to be that glossary of features.

Have added a link to the list of features.

> For "not applicable," I think we do need to list that for the tool. I think
> there should be a required "rationale" comment box for this option as well.
> I would like to know why it is not applicable. 


I think vendors have an incentive to add as many features as possible, because that makes their tool listing show that they support many accessibility features. If they leave something out as not applicable, while it was in fact applicable, it seems to me that's their loss. 

For users, to see the reasoning, might make the tool listing look more complicated?

With “not applicable” features not listed, they will see a list of just the features that the authoring tool has. If we do display “not applicable” features, they will need to filter out mentally the ones that don't apply or read why they don't? I am worried that that level of detail, while I appreciate it is helpful for few, gets in the way for many.


> Need to have a very structured way of listing all these features in the
> "details" area of the tool. So they are consistent in order and location
> from tool to tool.

I agree.  If I don't do anything unusual when coding the tool, order should be the same, because it will be outputted by the same tool.

> Prototype looks good so far.

Thank you! 

—

Hidde de Vries
Web Accessibility Specialist

Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)