From Span Title to Abbreviation
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?
Groups:
Login to post 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"?
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
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