Closed (fixed)
Project:
Ubercart
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
16 May 2009 at 17:10 UTC
Updated:
3 Jan 2014 at 00:29 UTC
Jump to comment: Most recent
In the checkout form page, there are some potential inaccessibility HTML code like:
* /table to make the form layout. It must be replaced with a /div /p structure.
* It don't use /label tag to notify an input label. Please, always use /label tag.
* When an error ocurre, the 'error' class will be assigned to the element that involves de /label and field. In this example is the /p element:
<p class="error"> <label for="address">Address:</label> <input type="text" id="address" size=50" ... /> </p>
Comments
Comment #1
rszrama commentedComment #2
rvilarCheck this issue for the new release
Comment #3
tr commentedTagging.
Some questions:
On the checkout form, the tables are used for layout, and that should change, but it's a big job. Ubercart uses many other tables. A lot of those tables are for displaying tabular data, which is appropriate. Are tables inherently in-accessible, and if not, why are the tables on the checkout page a bigger problem than anywhere else?
What does this mean? The slashes (/) in your post confuse me - can you write <label> and </label> if that's what you mean? You can enclose HTML in <code></code> tags so it displays the way you want it to.
That would be a problem with Drupal, not Ubercart - the Drupal function form_set_error() should be adding that tag if it is needed for accessibility. You should raise that issue in the Drupal forums / issue queue.
Comment #4
rvilarYes, tables are only for tabular data, but sometimes Ubercart use these elements for layout tasks. We have to avoid only it use in layouts.
In the checkout page, we have this HTML (example):
For accessibility purposes, each form element have to be associated with a label element. For this example, the code must be (avoiding table use):
Comment #5
longwaveThis won't be changed in 6.x-2.x now, and 7.x-3.x is better in this regard so I think this can be closed.
Comment #6
Everett Zufelt commentedI don't know if this branch is EOL, but for native (to the markup language) form elements that do not have labels, adding a title will improve accessibility.
$form['myelement']['#attributes']['title'] = t('My label');
Also, although tables shouldn't be used for layout, they are meant for tabular data, there is nothing in WCAG 2.0 that states explicitly that they should not be used. using the attribute role="presentation" on a table can tell assistive technology to ignore the table semantics.
Comment #7
tr commentedUbercart 6.x-2.x is not EOL until D8 comes out, but we're not planning to put major effort into new features in D6 at this point. As @longwave mentioned in #5, we think this issue is pretty much fixed in D7, but the way it was done can't be backported to D6. If someone wants to contribute a patch for this in D6 we'd be happy to review it, but it's not something the maintainers are going to be working on.
Comment #8
hansrossel commentedA workaround for this important accessibility problem is to use http://drupal.org/project/uc_webform_pane, this way the forms are made by webform and those are accessible.
Comment #9
longwaveWe can't remove the tables now in 6.x, seems like the only real tasks here are to ensure that all fields have labels, and perhaps add the role="presentation" as mentioned in #6.
So far in this issue we've identified that the address fields need correct labels, also #1617240: Adding field titles for accessibility identified the same problem in the credit card form.
Comment #10
longwaveCommitted fixes for both sets of fields. Kinda ugly code but the best we can do while avoiding breaking existing themes. We don't use ARIA roles anywhere else, so that can be left for another issue.
Address fields: http://drupalcode.org/project/ubercart.git/commitdiff/207ebdc
Credit card fields: http://drupalcode.org/project/ubercart.git/commitdiff/fa8c517