Accessiblity: Orphaned form labels

[Dawnzar]

WCAG 2.0 - Success Criteria -

1.Go to: http://data.ottawa.ca/dataset/new

2. View several form labels present but do not match the input field. This is present throughout the form.
3. Resolution example below:

[deniszgonjanin]

This is an issue with the Wave toolbar - each of the form labels is associated with an input element. The issue here is that the input element in question is not an tag, it is instead a div with the HTML5 "contenteditable" property (see https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable)

For example, here is a snippet of code from the page for one of the elements in question:

<label for="field-accuracy-editor-fr">FR Accuracy</label>
<div class="controls">
    <div class="editable medium-editor-placeholder" id="field-accuracy-editor-fr" contenteditable="true" data-placeholder="Type your text" data-medium-element="true">

    </div>
    <input type="hidden" name="accuracy-fr" value="">
</div>

You can see that the label is associated with a matching element.

I would say this is an issue with Wave not recognizing that labels can be associated with

elements in HTML5. It shouldn't negatively affect accessibility in any way

[Dawnzar]

The label is being associated with the div. The label should be associated with the input field and it is not. For example: Question - why is the input field outside the

tag?

When a user has used tabs to navigate to the input field then it will read the question.

[deniszgonjanin]

Yes, the label is associated with the div that is the actual input that the user enters the text in. As you have noticed, there is an actual input there that we could associate with the label. That will make the WAVE tool pass this test, but I don't think it's the right thing to do from a Usability point of view, since the label would be pointing to a hidden input element.

If making the WAVE tool pass the test is what matters, I can make the necessary changes. We can convert those labels to different elements, and use the aria-labelledby attribute to associate the appropriate div to the appropriate description instead for Accessibility purposes.

[Dawnzar]

@webstandards

[webstandards]

@Dawnzar the deciding factor would be to test it in a current screen reader like NVDA or JAWS if the labels are being read out as labels then it's good. Otherwise using a new HTML5 feature screen readers don't yet support is just as bad as using a new HTML5 feature the browsers don't yet support for sighted users.

Tools like WAVE give you things to review, it's testing with a Screen Readers that tells you what needs to be fixed just like you test in Browsers for sighted users.

[deniszgonjanin]

I'm not sure how much this matters, but another thing to note is that this particular feature (entering metadata when publishing datasets) is only exposed to internal users of the site - city staff who work on publishing Open Data. It is not something a regular visitor to the site would ever encounter.

[giggey]

That would definitely matter. Our requirements are based on external users only. Internal accessibility would be considered a 'nice to have' at this time. Focus would be on external users. Thank-you.

[Dawnzar]

Resolved.