Taxonomy term reference field headers always should be rendered with a HTML header (invisible or not)

It's the same issue as #364219: Navigation menus should be preceded by headings of the appropriate level (usually <h2>).

or http://webaim.org/standards/wcag/checklist#g1.3

I was proposing keeping with the hidden/invisible framework that's used in CSS could be re-used for consistency.

So this is an example right now with the header hidden.

<div class="field field-name-taxonomy-vocabulary-3 field-type-taxonomy-term-reference field-label-hidden clearfix"> 
    <ul class="field-items"> 
          <li class="field-item even"> 
        <a href="/html5" typeof="skos:Concept" property="rdfs:label skos:prefLabel">HTML5</a>      </li> 
          <li class="field-item odd"> 
        <a href="/topic/accessibility" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Accessibility</a>      </li> 
      </ul> 
</div> 

There should be an option like this:

<div class="field field-name-taxonomy-vocabulary-3 field-type-taxonomy-term-reference field-label-inline clearfix clearfix"> 
      <h3 class="element-invisible">Topic</h3> 
    <ul class="field-items"> 
          <li class="field-item even"> 
        <a href="/html5" typeof="skos:Concept" property="rdfs:label skos:prefLabel">HTML5</a>      </li> 
          <li class="field-item odd"> 
        <a href="/topic/accessibility" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Accessibility</a>      </li> 
      </ul> 
</div> 

There are no LABELs involved as such. It's labeling a list, but wanted to make that minor clarification.

I set this back as a bug as it's really no different than any other list of links in core. You have to be able to understand the context of the group of links.

So in it's simplest form it could just be:

function theme_field($variables) {
  $output = '';

  // Render the label, if it's not hidden.
  if (!$variables['label_hidden']) {
    $output .= '<div class="field-label"' . $variables['title_attributes'] . '>' . $variables['label'] . ':&nbsp;</div>';
  } else {
    $output .= '<div class="elementi-invisible"' . $variables['title_attributes'] . '>' . $variables['label'] . ':&nbsp;</div>';
  }

However there is no need to include a hidden label for anything other than a list. There's no need to have this setting do anything different than what it does for the body or title elements. Although I'm not sure how to select for $element['#field_type'] & pick out only those fields where the output requires a heading inorder to group the items together in context.

EDIT: Jeff, that's definitely an odd output. What code did you use to manipulate the array?

It's certainly something to think about. Perhaps pushing it back to the theme layer is more appropriate so that this code could be stripped out of a super lean site.

However, by by default we need to aim to have a site which is at least WCAG 2.0 A. We can be confident if it is something that has be be added in by individual themes and isn't in core (even just the core themes) that it isn't something that the vast majority of people will do.

When I look at managing fields of a particular content type, say admin/structure/types/manage/blog/fields

The Term reference field is a UL list which needs a HEADING label for accessibility.

I don't think that the other field options (which include for me Boolean, Date, Datestamp, Datetime, Decimal, Email, File, Float, Image, Integer, Link, List, Longtext, Longtext & summary & Text) would produce LI's (either ordered or unordered) so would never need to have a H2, H3, H4 or similar heading label present for accessibility reasons.

Any UL or OL list (whether it has one item or 50) should be have a heading to provide context for screen readers. That could be invisible or not.

So then we should at the very least patch bartik, include the themable theme_field__taxonomy_term_reference() function into other core themes & include this as part of the process for themes for D8.

Arg. There are times... vi.. Sorry..

Anyways, here's a new patch.

The comment also probably needs some help:
// Render the label either as a visible list or make it invisible for accessibility.

Then I'll work on patches for Seven & Stark. Or just Stark? Why would there be a Seven admin theme in D8?

Man... Hope this gets it. And thanks @yched for posting on the Fix taxonomy term display issue.

Nope. Sorry Jeff. I think that was a cut/paste error. Let me re-roll that one.

Seemed to make more sense to consolidate it as:

  // Render the label either as a visible list or make it invisible for accessibility.
  $label_class = (!$variables['label_hidden']) ? 'field-label' : 'element-invisible';
  $output .= '<h3 class="' . $label_class . '">' . $variables['label'] . ': </h3>';

Since it's all the same other than the class.

#25: taxonomy_terms_need_headings-1106344-25.patch queued for re-testing.

Updating patch.

Not sure why Bartik has decided to deviate on this.

#28: taxonomy_terms_need_headings-1106344-28.patch queued for re-testing.

#28: taxonomy_terms_need_headings-1106344-28.patch queued for re-testing.

@Jeff as usual you raise good points.

We don't set up WCAG's guidelines, but do need to try to work with them where we can. List elements need to have a header so that screen reader users can navigate between them.

Now, I'm not exactly sure how to deal with your bigger issue (which should be it's own issue). If you want to show the element it is a bit silly to have to write a theme function.

There's really now way to override it with CSS? Hmm.. Maybe we need something with Javascript. Not sure.

Adding headers to lists was a step ahead for some users, but apparently not for all.

If we get this in core then the D8 is more consistent. Then maybe someone can write a simple module that collects references to element-invisible & can remove them via some UI.

I'm not exactly sure how that would work, but want to make sure I understand.

#28: taxonomy_terms_need_headings-1106344-28.patch queued for re-testing.

Changing the title for clarity (I hope).

#28: taxonomy_terms_need_headings-1106344-28.patch queued for re-testing.

#28: taxonomy_terms_need_headings-1106344-28.patch queued for re-testing.

Going back to comment #19 for the interdiff I'm posting here to the latest in #28.

Going back to comment #19 for the interdiff I'm posting here to the latest in #28.

#28: taxonomy_terms_need_headings-1106344-28.patch queued for re-testing.

Reroll for bartik.theme filename change.

@catch, sorry, but I don't understand why.

The patch in #43 just leverages $variables['label_hidden']

I can't see how it would affect the template_preprocess_field()'s:

  $variables['label_hidden'] = ($element['#label_display'] == 'hidden');
  $variables['label'] = $variables['label_hidden'] ? NULL : check_plain($element['#title']);

Is this a bigger problem with the label_hidden? What am I missing?

tagging. Hopefully some clarity will help move this issue forward.

Ok, so if I set this up so that the Label is Hidden (changed from Above) here:
admin/structure/types/manage/article/display

I should then be able to just add an article with a taxonomy. Then realized the patch needs to be updated to use "visually-hidden" which is now in Core.

Here's a re-roll.

#49: taxonomy_terms_need_headings-1106344-49.patch queued for re-testing.

#49: taxonomy_terms_need_headings-1106344-49.patch queued for re-testing.

Prior test failed with:

The test did not complete due to a fatal error. Completion check TrackerUserUidTest.php 33 Drupal\tracker\Tests\Views\TrackerUserUidTest->testUserUid()

Which seemed like it could be a bot issue, especially with this simple code.

#49: taxonomy_terms_need_headings-1106344-49.patch queued for re-testing.

#57: taxonomy_terms_need_headings-1106344-57.patch queued for re-testing.

I tested this and it works as expected. When setting the Label as hidden

Before patch

After patch: