To help author more accessible content (according to ATAG 2.0) adding specific documentation on D8's accessibility will help people learn what is. In ATAG A.4.2 they outline in more detail best practices in "document the user interface, including all accessibility features."

So on the help pages here /admin/help/views_ui we could add a section at the bottom, something like:

<h3>Accessibility</h3>

<p>With the incorporation in Drupal 8, Views UI accessibility has been improved to better meet WCAG standards. </p>

I expect that there are more elements that can be included.

Comments

jhodgdon’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +VDC

We do not want to talk about evolution in hook_help(). We want to document what module's currently do and how to use them.

So the above text is not appropriate for hook_help(). It might be appropriate for going on a "What's new in Drupal 8" or "Accessibility improvements in Drupal 8" page on drupal.org, but not in hook_help().

If there is something specific to document for the Views UI module, then we should document it. The ATAG guidelines say we should document: how to use accessibility features -- either features that (from the other guideline) "make the authoring tools themselves accessible" or ""help authors create more accessible web content".

Are there such features in the Views UI module that we need to document?

Also, we need to think about where to put them. hook_help() is separated out into About and Uses. If we are documenting how to use accessibilty features, they should go into Uses -- and each one is a header starting with an -ing verb.

mgifford’s picture

Status: Postponed (maintainer needs more info) » Active

This is probably the biggest UI change to alert users to https://www.drupal.org/node/843708

Just letting them know that they can set caption & summary elements through the UI for tables is useful.

I don't know if it is worth telling them that header/id's are also provided by default in tables.

So many improvements have been made to the Views UI, for accessibility, but I don't think those would need to be mentioned.

jhodgdon’s picture

Again, we do not want to talk about *improvements* to Drupal 8. We just want to document what it is, now, without reference to the past or the future. We shouldn't leave out important things just because they've been around a long time, or specifically mention new things just because they are new.

And the main things to document in the hook_help() in this issue are not features per se, but things where, when someone is creating a view, they would need to take action to make sure the view is as accessible as possible, such as maybe saying that when they make a table view, they should add a caption and summary (or whatever the recommendation is).

And also we'd want to document if there are things users who are blind, have low mobility, etc. would need to do in order to use the UI (things like turning on the "display row weights" when you're ordering a menu if you cannot drag and drop for whatever reason).

But I don't think we need to document here (maybe on a drupal.org page or a blog post somewhere instead?):
- Things that Views is doing better than it used to do in the past
- Things that Views does for you automatically to make your views more accessible
- Things that the Views UI module does to make its UI more usable by blind people that don't require them to do anything to turn them on
- etc.

Right?

mgifford’s picture

Status: Active » Closed (won't fix)
Related issues: +#2308521: Document accessibility features in Views

I'd forgotten about #2308521: Document accessibility features in Views and that we've already talked about caption & summary elements as well as header/id.

Having a blog page to talk about the improvements makes sense. I'm closing this for now. Hard not to talk about the improvements that we've been working on for so long.... But agreed that it doesn't make sense to include that in the help docs.

Thanks!