Add additional headers to Views UI

@ezra-g

Adding the headings do not need to change the visual style of the page, they can be used as semantic markup alone. Being blind I tend, as much as possible, to stay away from making any style suggestions.

The headings that I have suggested are already text within Views UI, the text is just not marked up as a heading. I assume, although I could be wrong, that the text I have identified may already be styled slightly differently than the surrounding text, as it represents separation of the logical sections of the UI.

@dereine

Correct, switching those divs to h3s would do the trick. Also correct that I got the wording wrong on "Live Preview" and it is already a heading (I wrote the issue in a hurry).

@merlinofchaos

I think you are talking about:

Change settings for this style
Style:
Unformatted
Change settings for this style
Row style:
Fields

It is confusing at first, and does contribute to the learning curve. Could we change the first image alt to "Change settings for Style" and the second to "Change settings for Row Style"?

Also, for Relationships, Arguments, Fields, Sort Criteria, and Filters, there is a Rearrange and Add image link. Could the alt be changed to add more context (e.g. "Rearrange Relationships" and "Add Relationships")?

@merlinofchaos

Possibly also this code

    <div id="views-ajax-title">

could be changed to an H? tag?

Can you please tell me what that div is used for?

We also use some classes like 'defaulted' and 'overridden' to provide a quick indicator if a setting is using the default display or has its own override. There might be a more accessible indicator we could add?

I've been giving that some thought. There is a trade off between too much and too little textual affordance. Too much makes listening to the page being read a burden, as it means hearing "default" or "overridden" after each option. Too little means not understanding what exactly is going on. Once a user selects a setting to change they are informed that they are either modifying the default or an overridden value, so I think this will be alright.

Also just noticed that Theming Information identifies some templates by bold font alone.

I actually have no idea of how best to represent this, but will give it some thought.

I am curious if there are any status messages on the UI that update automatically when actions are performed (excluding the Live Preview)?

If there are, and there may not be, the container for messages could receive the attribute role="status"

<div role="status">

This is a WAI-ARIA 1.0 role that indicates that the region should be monitored for updates, and that those updates should be presented to the user. The actual monitoring and presentation of the content is handled by the user agent. For example, screen-readers that support the status role will usually speak the content to the user, but in a way that doesn't interrupt what they are currently typing / reading.

Resource:
The Roles Model... : status (role)

Alright, I now see that the list of template files under Theme Information can be selected and the template shown *** awesome *** .

But, they are all being read as plain text, so a screen-reader user has no idea that they are actionable unless they make a guess, use the virtual mouse cursor (usually awkward to do), and try to click one. Would it be possible to mark these up as links? Again, the style doesn't need to be altered, just the markup. It would also be useful, but not at all necessary, if they were each an item in an unordered list. As links we can also indicate the bold items with some hidden markup by using the .element-invisible class from D7 core.

Example markup:

<ul>
  <li><a href="#">foo.tpl.php</a></li>
  <li><a href="#">foo-bar.tpl.php</a></li>
  <li><a href="#">foo-bar-foo.tpl.php</a><span class="element-invisible"> (active)</span></li>
</ul>

/**
* Hide elements visually, but keep them available for screen-readers.
*
* Used for information required for screen-reader users to understand and use
* the site where visual display is undesirable. Information provided in this
* manner should be kept concise, to avoid unnecessary burden on the user. Must
* not be used for focusable elements (such as links and form elements) as this
* causes issues for keyboard only or voice recognition users. "!important" is
* used to prevent unintentional overrides.
*/
.element-invisible {
position: absolute !important;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}

@dereine

Thanks for the patch. Can you please tell me which version of Views to apply this patch to? I received some failures when applying to the D6 recommended version (downloaded with drush).

I do have javascript enabled. Are you saying that when you select an item to configure that the configuration settings appear in something like a jQuery modal dialog? If so, then it would be good for the title of that dialog to be a heading.

Thanks again

I am guessing that the patch is for 6.x-2.x-dev... I'll try this later today.

Ok, I now realize that the template files that are listed under Theme Information are * not * actionable. So, ignore what I said about links above. list items and the hidden span for the active item still a good idea.

Can you please give me the cvs command to checkout 6.x-2.x-dev. I thought it was:

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d views/ -r DRUPAL-6--2 contributions/modules/views

But hunk 3 in includes/admin.inc is failing to patch

@merlinofchaos

The piece of code I mentioned is the javascript embedded title for the form, but you reader is probably not actually using that (which I should have realized)
so it can be ignored.

Most modern screen-readers read directly from the DOM and update their buffers on DOM events. So, it is likely that I do have access to that element.

@dereine

Tested the patch against 3.x

What I notice is that the Add / Rearrange links now have names with more context e.g. Add Fields Rearrange Fields, excellent.

I didn't notice any additional headings.

Also, just to clarify, the role="status" only needs to be applied to a container if its contents will be dynamically updated with Javascript. So, if the status message doesn't do this we don't need the role.

Also, and this may just be the quirkiness of the screen-reader, when a user makes a selection (like clicking on title to set a title), focus should move to the area where the settings are actually entered.

Thanks again.

Putting a heading on the title should be sufficient.

The rule of thumb with the live region "status" thing is to place it on containers for content that updates without the user initiating an action, or that is informative only.

E.g.

Updating stock prices / sports scores
Updating status messages

Since the user is intentionally invoking the behaviour that brings up the form it doesn't need to be a live region.

@dereine

Just to confirm, I did my testing on 6.x-3.x I'll keep doing that. Unless it is easier for you for me to test on 7.x-3.x, I can do that too if you like. Whatever is best for you.

Perhaps later this week.