Posted by mgifford on March 25, 2009 at 7:07pm
So I was reading Practical Accessibility Tips with WCAG 2.0
Always Use Explicit Labels is in 7 core now and has been backported ot 6.
The use the tabindex attribute is also quite scarce. Think it only shows up in the user.module as an attribute added to the form:
'#attributes' => array('tabindex' => '1'),Right now we're indicating Required Fields using:
<label for="edit-name">Username: <span class="form-required" title="This field is required.">*</span></label>However, I believe the WCAG 2.0 way for required fields is would be:
<label for="edit-name">Username: <span class="form-required"><abbr title="This field is required.">*</abbr></span></label>It's just a simple change on line 2467 of includes/form.inc
$required = !empty($element['#required']) ? '<span class="form-required" title="' . $t('This field is required.') . '">*</span>' : '';There are no instances of the use of the abbr tag in core other than the filters.
Some questions.
1) Would inserting a tabindex be useful or is the order of the form elements clear enough?
2) Will screen readers interpret abbr more consistently than a titled span element?
Comments
tabindex is not useful.
Avoid tabindex
So I was reading Practical Accessibility Tips with WCAG 2.0
Ironically, I just read that article yesterday. It was interesting to learn something new.
1) Would inserting a tabindex be useful or is the order of the form elements clear enough?
No, inserting tabindex won't be useful. v said it right, it will create an illogical tab order.
2) Will screen readers interpret abbr more consistently than a titled span element?
This is a really tough and difficult question to answer.
I think the question really boils down to how the user configure his/her screen reader.
See http://www.isolani.co.uk/blog/access/ConfiguringLinksInScreenReaders.
BTW, what about looking at WAI-ARIA's aria-required="true"?
Mike
Initial Focus & Default Elements
So is the only way to ensure that say the user registration takes less than 20 tabs to get the first relevant form element to move the main column to the top of the theme and ensure that all block areas are presented after the main content but styled appropriately so that they display correctly? Is there a better way to just ensure that the first tab element starts in the right place? mentioned the tab's in a prior post due to watching my friend to login.
So what are the default settings for JAWS? What are the most common settings? Surely JAWS is collecting this? Can we assume a text|title|alt|href priority?
Thanks for considering this "practical approach". Too bad it wasn't more applicable to Drupal.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
initial focus can be auto focus
Many will argue for auto focusing of the cursor. If you go to most any WordPress weblog post and start tabbing, you'll find that the TABINDEX will take you directly to the comment form. That's the purpose of this page, more or less, but that is debatable. Most sign in pages will do the same thing, auto focus on the sign in form. This is more of a Usability issue rather than an accessibility issue.
On another note, most screen readers will open a dialogue when they arrive at a webpage. The dialogue can be either a list of links, a list of headings, or a list of forms and their form fields. This is how they will navigate where they need to.
All this being said, you can read what is said about the focus order in WCAG 2 and find out that TABINDEX ain't all that bad.
Focus should be logical
Hey v, thanks for the push to reach out to the usability folks. I posted a link here - http://groups.drupal.org/node/20663
Think this needs more testing, but I'd think that anytime you're in a url with /user*, /node/add*, or node/*/edit the focus should stay with the form. though not sure how that affects the other elements (in the form or in the page).
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Required fields vs Optional fields
I did always wonder whether that was the best way to go about things so, for a few years now, I have simply added a span of (optional) into the label of any field that ISN'T compulsory. And, instead of adding "* = required" or something similar at the top of the form, I use "Unless marked as optional, all fields are required."
Having the system read "optional" instead of "asterix" seemed more sensible to me. And by reversing the old-logic completely - telling people to expect that ALL fields are required - I figured you could vastly reduce the possibility of someone missing a compulsory field. At worst, someone might complete every field including the optional fields, but as my optional field labels clearly state optional e.g. "Age (optional)" that seems unlikely to me even in forms mode.
I spotted, today, that this approach is being used by Fix the Web (http://www.fixtheweb.net) the accessibility task force which certainly makes me feel more confident that I am on the right track.
Regards
Sue
Optional vs Required
I often figure that using what's common on the web is easier for folks to understand & expect. Even if it isn't an ideal situation, it is what folks expect to find.
As far as looking at other forms & how things are done, I like this one:
http://www.actionforblindpeople.org.uk/other-pages/contact-us/
but it uses a span around the * - could be that it makes no difference to AT users and everyone just knows what it stands for at this point.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
"required" seems cognitively simpler
I think special "reverse-geared" instructions like "Unless marked as optional, all fields are required" break the "don't make me think" rule. This is obviously a usability thing, not accessibility. More often than not, the two are related, though.
In all of the two minutes I looked at Fix the Web, I was horrified that they seem to be portraying Web accessibility as being exclusively about disability. Very disappointing. I'm not sure, but they may also be restricting themselves to input from people with disabilities (if you have no disabilities, it must be usability?). Thanks for showing it to me, though. Sometimes I think I do live under a rock :)
span element is redundant
Using the
<abbr/>element is on the right track for asterisks. I've always considered an asterisk as an abbreviation, not sure why it takes WCAG2 to bring this out.However, the surrounding
<span/>element is not needed, as you can put the class attribute on the<abbr/>element. The way I see it, span only serves to provide a wrapper where none exists. Why create markup bloat? Drupal is quite guilty of this in many places.My other (much more pedantic) comment about the original post is that "This field is required" is a touch verbose and arguably even patronising. "required" would be ample in this context in my opinion. We are in the context of a symbol representing something, and it represents "required".
In answer to your two questions:
<abbr/>. It's surely a bread-and-butter element for them.And I've only just noticed this is quite an old thread. Apologies if we've all moved on.