All Input Tags are not Section 508 Compliance

[dmo7]

Not all of the input tags within the Wordpress admin console are section 508 compliant (​http://www.section508.gov/). We have scanned the application using compliance software and found many instances where input tags (checkbox, text, textarea, file, radio, etc..) are missing the required label or alt text. (There are many instances where it IS compliant.)

We (developers at a government agency) have the ability to make the changes, but some of the decisions for which exact text to put in the labels and alt text should probably be decided by a more dedicated Wordpress developer. Please contact me if you want our help or input.

We believe that the software is extremely close to 100% compliance. Bringing it to 100% would be a huge deal for government agencies wh are trying to get approval to install and run Wordpress internally and externally.

[ryan]

A patch is welcome. We can tweak the text if needed.

[hakre]

ryan, I guess is that the reporter needs assistance in form of feedback from a dev. dmo7: can you provide an email address so that it is easier to contact you?

[aox7]

Hello, dmo7 is currently at a conference but I can follow-up in his place. We would be happy to do the PHP work, but feedback from a dev would be helpful. What is the best way to provide contact information? It looks like I can't add an email address.

[ryan]

Just use this ticket for communication. That way anyone can answer and no one is stuck waiting for me to wade through my inbox. :-)

[DD32]

If you're stuck on the actual text for a lable or alt, Feel free to submit a .diff from (preferably trunk, but latest stable will do) with placeholders, ie. alt="TODO"

While it would be nice for you to do all the work :), Its fair enough that you might not have the required knowledge of -all- affected parts to decide what text should be used.

[aox7]

We will get the code done as soon as possible; it may be next week because it is spring break here. It is really nice for us to be able to give back to the community instead of paying to customize proprietary software. We are using WordPress MU, will the changes we make to WordPress be replicated to MU or is it a separate SVN trunk?

[ryan]

WPMU merges all changes made to WP.

[Denis-de-Bernardy]

See also: #9419

[dmo7]

Hi. I'm attaching a patch file. This is our first cut at the changes. I've added alt="TODO" for all input fields needing it. This is my first time contributing, please let me know if I'm doing anything wrong or if I'm submitting the patch in the wrong way.

I'm going to mark this as "fixed", but after additional tests, we may need to make a couple more updates. Is that ok or do you want me to wait and submit a new patch after we're finished?

Thanks.
Dave

[filosofo]

It's not "fixed" until committed.

[ryan]

Aren't labels preferred to alt for text inputs these days?

[dmo7]

This is the updated patch. A couple more changes included.

[hakre]

dmo7: Thanks for taking care.

[ryan]

(In [11149]) Add labels to titles. see #9445

[ryan]

We'll probably use labels instead of alt since that's what we do everywhere else and it seems to be preferred over alt.

I notice the patch adds alt to some hidden inputs. Is that needed? They aren't displayed after all.

[ryan]

(In [11152]) Add labels to text inputs. see #9445

[Elpie]

ALT text should not be used on inputs at all.

Care also needs to be taken with labelled fields. Using the class="hidden" doesn't just make the label hidden to standard browser output but also hides it from most assistive devices, essentially meaning that a lot of work is being done in WordPress with the intention of aiding accessibility but which is not.

Anything using CSS display:none is not discovered or spoken by screen readers.

For example the excerpt is a labelled field, but the label is hidden with CSS "display:none". This makes the label non-existent to Jaws. There's also no title attribute for Jaws to recognise.

[Elpie]

From WCAG 2.0: H44: Using label elements to associate text labels with form controls
​http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H44#H44-description

The objective of this technique is to use the label element to explicitly associate a form control with a label. A label is attached to a specific form control through the use of the for attribute. The value of the for attribute must be the same as the value of the id attribute of the form control.

The id attribute may have the same value as the name attribute, but both must be provided, and the id must be unique in the Web page.

This technique is sufficient for Success Criteria 1.1.1, 1.3.1 and 4.1.2 whether or not the label element is visible. That is, it may be hidden using CSS. However, for Success Criterion 3.3.2, the label element must be visible since it provides assistance to all users who need help understanding the purpose of the field.

Note that the label is positioned after input elements of type="checkbox" and type="radio".

Note 1: Elements that use explicitly associated labels are:

• input type="text"
• input type="checkbox"
• input type="radio"
• input type="file"
• input type="password"
• textarea
• select

Note 2: The label element is not used for the following because labels for these elements are provided via the value attribute (for Submit and Reset buttons), the alt attribute (for image buttons), or element content itself (button).

• Submit and Reset buttons (input type="submit" or input type="reset")
• Image buttons (input type="image")
• Hidden input fields (input type="hidden")
• Script buttons (button elements or <input type="button">)

Hope this helps.

[ryan]

Replying to Elpie:

ALT text should not be used on inputs at all.

Care also needs to be taken with labelled fields. Using the class="hidden" doesn't just make the label hidden to standard browser output but also hides it from most assistive devices, essentially meaning that a lot of work is being done in WordPress with the intention of aiding accessibility but which is not.

Anything using CSS display:none is not discovered or spoken by screen readers.

For example the excerpt is a labelled field, but the label is hidden with CSS "display:none". This makes the label non-existent to Jaws. There's also no title attribute for Jaws to recognise.

I've heard JAWS reads these fine. We put a lot of hidden labels in at the request of JAWS users.

​http://www.wac.ohio-state.edu/tutorials/forms/hiding-labels.htm

[hakre]

+1 for display:none. And even if jaws would not read it fine, then jaws would not be in conform with Success Criteria 1.1.1, 1.3.1 and 4.1.2. So Jaws should fix that if it wants to be conform with WCAG. I hope it tries that and it does not use it's position on the market to create an Internet Exploider for the Blinds.

[Elpie]

Replying to ryan:

Replying to Elpie:

ALT text should not be used on inputs at all.

Care also needs to be taken with labelled fields. Using the class="hidden" doesn't just make the label hidden to standard browser output but also hides it from most assistive devices, essentially meaning that a lot of work is being done in WordPress with the intention of aiding accessibility but which is not.

Anything using CSS display:none is not discovered or spoken by screen readers.

For example the excerpt is a labelled field, but the label is hidden with CSS "display:none". This makes the label non-existent to Jaws. There's also no title attribute for Jaws to recognise.

I've heard JAWS reads these fine. We put a lot of hidden labels in at the request of JAWS users.

​http://www.wac.ohio-state.edu/tutorials/forms/hiding-labels.htm

The page you reference is VERY outdated.

"display:none" and "visibility:hidden" are designed to prevent the element from being rendered on a browser screen. Screen readers read the screen. Several years ago a combination of browser bugs + bugs in JAWS and Windows EYES resulted in *some* content that was hidden by "display:none" being able to be read by those screen readers. This was not consistent across all screen readers or other assistive devices, and was not consistent across browsers.

Internet Explorer bugs meant this was the last browser to allow content hidden by "display:none" to be viewed. JAWS has addressed this: ​http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp
"JAWS no longer announces input fields that are hidden from view by a cascading style sheet."

It is generally accepted among those of us who work with accessibility that labels should either be available to everyone, or, in those few instances where additional labelling benefits only those using assistive devices, then using a margin offset wider than a screen makes those labels hidden from view but able to be read.

Where WordPress has correctly used labels, it should first be determined whether the labels could be made visible to everyone (which would save a lot of work) or, if they need to be hidden then its a simple change - instead of "display:none" in the .hidden element in CSS, use a margin offset. I don't believe that they all need the class="hidden" & would be happy to submit a patch if agreement can be reached on which labels could be made visible to everyone.

[ryan]

Hidden inputs are different than hidden labels. It makes no sense to me to ignore a hidden label for a visible input, but I digress. We had a blind user who used to work at Freedom Scientific look over these not so long ago and all was deemed fine. We'll go with whatever the current thinking is though.

We can certainly look over all hidden labels and determine if they need to be visible to all. Just change the styling on the hidden class and see how horrid things look. I suspect it will be inaccessibly ugly. :-)

[ryan]

"JAWS no longer announces input fields that are hidden from view by a cascading style sheet."

To be clear, we're talking about hidden labels for visible inputs, not hidden inputs. Just in case it matters.

[ryan]

​http://www.w3.org/TR/2005/WD-WCAG20-CSS-TECHS-20050630/#creating-invisible-labels

[ryan]

Marco Zehe says to use offscreen positioning, so let's update our hidden class.

[hakre]

+1 I've talk with one of the css/webusability gurus here about that. He said that as well, this is best practice:

.nodisplay {
  position: absolute;
  left: -1000em;
}

for older screenreaders this is better has been said. older readers have problems with display: none; even though display: none; is in WCAG / 508 compliance.

[hakre]

I try to update the patch, but it looks hard to me because I can not directly apply it to the current trunk easily. Would be nice if the original patcher can update, I try to get back to an older revision and try to merge then.

[ryan]

(In [11175]) Hide things that need to be available to screen readers via offscreen positioning. see #9445

[hakre]

Updated against latest Trunk.

[hakre]

I've updated the patch against the latest Trunk. alt attributes should be replaced with labels according to this tickets discussion. I've seen that on some places labels have already be inserted and i've seen that ryan is taking care of comitting related to this ticket. But while updating the patch I've seen as well that some labels are bound to wrong inputs and not every alt="TODO" tagged input element has a label.

so there is some work to do to add labels. the alt="TODO"-makers in this patch help to locate those places and quality control already created label elements if they are bound to the right input element.

a question: is it necessary for submit buttons to have labels? normally they have already a decribing value, right?

[ryan]

​http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H44#H44-description

Note 2 says submits don't need a label.

[hakre]

Labels added. (plus update to the latest revision, new classname)

[hakre]

I've updated the patch and inserted label elements where I was able to. Missing translations tagged with __TODO__. In some/many places I was not able to create label elements because of missing function descriptions / docblocks. I will try to find out the places in the backend und extend the patch in a second iteration.

Then I do not really know, what to write. For example, if there is a checkbox, do I use the label 'Select Media-File' for the checkbox to select a Mediafile in the listing or do you use just plain 'Media-File' because the screenreader is aware that this is a checkbox? Woudln't it be more useable if the name of the concrete file is given or the numerical ID? This is interesting for all the places in the Backend where you have got tables and the ability to select multiple items to perform bluk actions.

Feedback and Help appreciated. This is my last patch for today for this ticket.

Additionally this patch includes changes due to the new invisible classname.

[hakre]

in the loop: ​http://wpdevel.wordpress.com/2009/05/03/going-through-some-of-the-accessibility/

[aox7]

I apologies for not re-engaging in this conversation sooner. We have been working 24 hours a day on H1N1 (Swine Flu) issues for the past 10 days. Please let us know how we can help to move things forward.

[hakre]

well patching the flu seems reasonable to me as well.

for me it would be good to know what wording to put into the label / alts. which character should such a text have? will it be spoken with the type of control that is connected to the label? how to deal with multiple select checkboxed (we have plenty of those, it must be hard to hear them all repeating)? can you give examples or make suggestions?

[Elpie]

Replying to ryan:

Hidden inputs are different than hidden labels. It makes no sense to me to ignore a hidden label for a visible input, but I digress. We had a blind user who used to work at Freedom Scientific look over these not so long ago and all was deemed fine. We'll go with whatever the current thinking is though.

We can certainly look over all hidden labels and determine if they need to be visible to all. Just change the styling on the hidden class and see how horrid things look. I suspect it will be inaccessibly ugly. :-)

Yes, in each case I was referring to the element, not the field.
Having a look at what is there, with the styling on the hidden class commented out would certainly show what could be displayed and what should be hidden :-)

However, I think you should be careful about making changes to labels for 2.8. There are some well-meaning, but misinformed folk around here and unless the changes are done properly there is a real risk that instead of improving accessibility, changes will harm it.

The alt tags that were suggested should not be committed. And the only change I would recommend would be to change the hidden class in CSS to use screen offset instead of display:none. This, on its own, will improve accessibility.

If the team sets up a wp-accessibility mailing list those of us who are proficient in ATAG, WCAG, and WAI-ARIA can get stuck in and bring forward accessibility patches for the 2.9 milestone.

[hakre]

Elpie thanks for your detailed feedback. I can only say that this kind of patch is a lot of work because it does interfere with many files. I strongly appreciate the idea that a taskforce is taking care of the implementations to be done so that precise information what to do can be provided for coders/patchers.

[Denis-de-Bernardy]

See: #9783

[ryan]

"How best to hide text"
​http://webaim.org/forums/viewtopic.php?id=356

[ryan]

As noted in #9783, Firefox shows labels that use our "invisible" class. I've seen some suggestions to put a span inside the legend and hide that.

[Denis-de-Bernardy]

this might work:

position:absolute;
left:0px;
top:-500px;
width:1px;
height:1px;
overflow:hidden;

will report back in #9783

[Denis-de-Bernardy]

reporting in here instead. I'm afraid it doesn't fix legends...

[ryan]

As suggested, let's do further work in 2.9 (and perhaps backport to 2.8.x) so we have time to discuss and do this correctly.

[hakre]

Replying to Denis-de-Bernardy:

reporting in here instead. I'm afraid it doesn't fix legends...

legends are a hard way to face css sometimes. that's pretty normal.

[Elpie]

Just adding a note here so its not forgotten...

One thing to remember about legends is that they are read aloud, before each and every label in the fieldset. So, if legends are added make sure they are brief and make sense when repeated before each label in the applicable form.

[GamajoTech]

How are the inputs and labels looking in 3.1 with respect to the issues raised in this ticket?

[grahamarmfield]

Anything happening on this?

[SergeyBiryukov]

9445.theme-zip-file.patch​ adds "Theme zip file" label, for consistency with the one in plugin-install.php (added in [11152]):
​http://core.trac.wordpress.org/browser/tags/3.4.2/wp-admin/includes/plugin-install.php#L149

[mikecorkum]

It seems that all the input tags are in compliance. It would probably be best at this point to log individual tickets if any additional items are found.