I have lurked for a little while, and this is my first post to this group. I have met some of you in person or virtually in other contexts, and appreciate your contributions to Drupal accessibility. In learning Drupal 7, myself, I have encountered some problems as a blind developer for which I have not yet found solutions (though I have done much reading of Drupal books and web articles). I hope some of you may have helpful thoughts on the following issues, divided into Blocks and Views; Content Types and Forms; and Status and Error Messages.
Blocks and Views
As you know, core or contributed modules often create blocks of information that need to be assigned to a region of the page in order to become visible to visitors. One problem I am encountering is deciding what regions to use for blocks that are not automatically assigned to a region. Right now, I am just using the default Drupal 7 theme. Can anyone give tips on where to place things? Are there conventions, or usability factors to consider, depending on the nature of the block? Are there guidelines for when a block should only appear on the front page, or be associated only with a particular content type?
Other layout-related questions are as follows: Conceptually, what are the distinct purposes of different menus, e.g., the main menu and navigation menus? Since the main menu and other menus can include aspects that seem related to navigation to me, I do not understand what is supposed to be different about the navigation menu, main menu, or other menus. Though I have read mention of them multiple times, I am still trying to conceptually grasp key differences intended among primary menus, secondary menus, site menus, user menus, and navigation menus. I know almost anything can be put anywhere, but what are some good rules of thumb for what to put where in a site with relatively conventional features?
I am also curious if anyone has tips on using the views and panels modules with a screen reader. Are there canned layouts that are easy to implement? If so, where might be a good place to start? So far, I have not found any step-by-step tutorials about setting up basic views with a screen reader, and other explanations naturally tend to be quite visually and mouse oriented.
Content Types and Forms
I noticed that the widget to choose multiple values via a "select list" does not seem to be usable with JAWS 10, whereas a set of checkboxes does work. Are there existing tips on what widgets tend to be more accessible than others for managing particular field types? For example, are any of the date-related widgets generally accessible with screen readers, or am I better off just using a text field with a custom format? I also noticed a widget for choosing tags which guesses as one types. I have not tried it yet, but wonder if others have tested it for accessibility.
After I created a content type, I noticed that JAWS would often read the wrong field label as I tabbed through the form to add a new record of that content type. I have noticed this with both the Bartik and Simpler themes, so wonder if it is a general accessibility problem in Drupal 7. Although I found accessibility evaluations of Drupal 6 themes, I have not found them for Drupal 7. Does anyone happen to have an opinion of Simpler versus Genesis or any other particular Drupal 7 theme with respect to accessibility?
I also have noticed that the help message related to the current field usually appears below it rather than above it. I think above is more intuitive, and wonder if that can be changed.
Status and Error Messages
I have not figured out a general pattern as to where such messages are placed. Often, though not always, I can find a status message (e.g., after pressing a Save button) if I navigate by heading. If there is a consistent way to look for such a message, it would significantly increase efficiency for nonvisual users. Is there a built-in pattern for placing such messages that I am missing?
Thanks for any help.
Jamal
Comments
Thank you for speaking up, Jamal!
You are asking very good questions. Some of what you're having trouble with — what kind of information is best placed in each menu, for example — is a problem even for those of us who can see, so I've tagged this discussion for the Usability group to help everyone get their input.
Although I can't answer your questions right away, I hope others can and will help. And please continue to do more than lurk. Your input is valuable!
Form Questions
Hi Jamal,
Thanks for the great feedback. I have a few follow-up questions to understand the situations you're describing.
First, when you say JAWS is "reading the wrong field label as I tabbed through the form to add a new record of that content type," can you provide the URL of the page you're on when that happens, and the name of a field that exhibits this behavior for you?
Second, you pointed out that "the help message related to the current field usually appears below it rather than above it." Unfortunately I cannot think of an easy solution to that because the sighted users want the visual UI to have elements in that order: the label, then the field, then the instructions/help. Does anyone have a clever solution that would put the instructions before the field in the HTML source order without messing up visual layout and without using Javascript?
Third, regarding status and error messages, they are always near the top of the page, after the page title, and identified with a H2 header. That should make them easy to find if you navigate the page using headers. Is there a markup or location that you would like to make it better?
-Brandon
www.pixotech.com
I have not thought about this
I have not thought about this before or tried this but would it helpful to do Field Label next to Help Text next to the field. So rather than it being a left -> right then top to bottom orientation it was moved to being all left to right.
This would not work well for visual users of the site because it breaks with the way "things are done" but maybe a style sheet could be loaded by role.
Interesting concept...thoughts?
Owner and Lead Consultant
Denver DataMan
Field labels and help text
I took a training program on accessible forms last year and the instructor said that when a screen reader like JAWS is in forms mode, it only reads form controls and label elements. When tabbing through a form, one is taken from control to control and, at each control, one hears the label for that control. Text outside of a label is not read. This means that it would skip the Drupal help text altogether, since it is not in a label.
The solution the instructor showed was to have a single label element (with a proper @for) containing the title and any associated help text. The title and the help can have their own wrappers within the label and use CSS to position them as desired. Example:
<label for="name_first"><span class="field_title">First Name:</span>
<input id="name_first" ...>
<span class="field_help">Name you are normally called</span>
</label>
It is permitted by the standard to have more than one label for a form control. So, it could be done like this:
<div><label for="name_first" class="field_title">First Name:</label>
<input id="name_first" ...>
<label for="name_first" class="field_help">Name you are normally called</label>
</div>
It looks good semantically, but I don't know how it would be read.
On error messages: The instructor also suggested that, if you are doing JavaScript form validation, a message like "form contains errors" be displayed by JavaScript in a label to the submit button so that the user will hear it before they try to submit the form. The message could also contain a link to the first error.
Breaking this down
Hey Jamal, thanks for posting this feedback. I look forward to hearing how these suggestions have worked for you.
I'd also recommend posting these issues separately to the Drupal issue queue:
http://drupal.org/project/issues/search/drupal?version%5B%5D=8.x&version...
It's definitely good to have them discussed here in the group, but ultimately we need them expressed in the issue queue.
Also, with the select lists, have you tried this with any other screen reader? AT really needs to work towards greater standardization.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide