Problem/Motivation

Currently Field Label visibility settings is like this (from field_ui_display_overview_form):

  • visible
    • above
    • inline
  • hidden (completely removed from the HTML output)

Um, I am very poor at wording something.

Ok. The problem is that the Field Label is either there or not there.

I wanted it to be there, but not visible.

For better semantics, I wanted the label not omitted from the html output, but it shouldn't be visible, we have a css class name that does that: "element-invisible", or make a new css rule like "field-label-invisible" (see template_preprocess_field).

We could have Field Label visibility settings like this:

  • visible
    • above
    • inline
    • invisible
  • hidden

Though I would prefer it like this:

  • visible printed out in html output
    • above
    • inline
    • hidden
  • hidden omitted

But it would break things like javascript etc :D.

Proposed resolution

This is the list of functions and templates involved in this issue:

Remaining tasks

Needs patch.

User interface changes

New or changed features/functionality in the user interface.

Select boxes values for Fields Label visibility in /admin/structure/types/manage/CONTENT_TYPE/display

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Everett Zufelt’s picture

This option seems like it would improve accessibility, however, I have no idea how we can word the UI text so as not to completely confuse 80% of administrators. Perhaps invisible / hidden should always render the label w/ .element-invisible, and anyone wanting the label to not be rendered should take care of this in a theme hook.

Bojhan’s picture

Yhea, I agree with Everett - its going to be really difficult to get this across, especially because hiding it but showing it in html is not a "best practice".

What about:

Invisisble
Removed

dozymoe’s picture

Added more background

Hidden label that help create context on a section of a page is very much in use (err, usable). Well, they aren't actually hidden, because screen reader will read them, for them it's not hidden.

While sighted people or one with CSS enabled in their browser would probably get visual cue that the current paragraph or Field is of a different context from the paragraph before it, having a label for the ones without would help, I think.

I do see the use case for when one just want the value of the Field and arrange these Field values in some manner.

Field value that stands alone as its own paragraph would need a label, I think.

HTML5 boilerplate has a catchy name for it, visually hidden.

User interface wise it is easy to understand if the <select> html element options label is "visually hidden". It's just that we already have "inline", "above", and "hidden", which are one worders.

Form API counterpart

OTOH, we have been using the phrase "invisible" in FAPI.

From theme_form_element_label:

// Show label only to screen readers to avoid disruption in visual flows.
elseif ($element['#title_display'] == 'invisible') {
  $attributes['class'] = 'element-invisible';
}

I think the options for #title_display are:

  • attribute
  • before
  • after
  • invisible
  • none

With invisible being the most used, but that's with HTML form element, and very few (if not none) actually touch the #title_display array element :(.

Other notes

I think the phrase "hidden" that core used is debatable, because in practice it's more like omitted or removed. And we have html form hidden element, which is there in code, but not visible (hidden), not removed in a sense.

If google want to complain about the hidden words (err, labels) they can kiss my beep.

Alex Komm’s picture

First attempt

Everett Zufelt’s picture

Status: Needs work » Needs review
bowersox’s picture

Can you explain the note "But it would break things like javascript etc". I don't understand how changing these options in Field UI would break JavaScript.

That said, I do believe changing the UI of core this significantly would not be allowed in 7.x. If I understand correctly, this would need to be a 8.x improvement. Please correct me if I'm wrong.

+1 for this suggestion!

Everett Zufelt’s picture

Version: 7.x-dev » 8.x-dev
Component: field_ui.module » field system
Category: feature » task

Yup, all patches are first written against 8.x, then considered for backport.

Everett Zufelt’s picture

Issue tags: -CSS, -Novice, -Accessibility

Status: Needs review » Needs work
Issue tags: +CSS, +Novice, +Accessibility

The last submitted patch, expose-field-labels-visibility-1361102-3.patch, failed testing.

dozymoe’s picture

@bowersox, I suspected the "hidden" options for field visibility might be used by the javascript that runs the "Manage Display" user interface. Sorry for the confusion.

That is if we consider renaming "hidden" to something else like "unused" etc (just found another possible options name :D). I think that one might be better than "omitted" or "removed". We need UX guys!

I think we also need a patch just to test if it's feasible to change the "hidden" label, I assume the automated testing system also tests javascript implementations.

May be contributed modules like views can also make use of this visually hidden label.

dozymoe’s picture

Also an interesting note is that the general solution for hiding block's title or headings is by using display: none;. Which is worrisome, I think that not many people is aware that we have css class "element-invisible".

I think I've read that using clip: rect(1px, 1px, 1px, 1px); for visually hidden content is found during the upgrade from Drupal 6 to Drupal 7?

After some googling :D, references: css-clip-hidden-content and using-css-clip-as-an-accessible-method-of-hiding-content.

Everett Zufelt’s picture

@dozymoe

There is currently no automated JS testing of Core.

mgifford’s picture

@dozymoe - those css references ultimately are tied to the work of D7. I hadn't seen the one from Yahoo! Accessibility, but it was interesting. Jonathan Snook (who is also with Yahoo!) gave a good write-up about it here http://snook.ca/archives/html_and_css/hiding-content-for-accessibility

Future directions for D8 on this should look at - http://groups.drupal.org/node/120224

mgifford’s picture

Status: Needs work » Needs review
FileSize
2.94 KB

Just moving the patch forward.

dozymoe’s picture

Instead of forcing element-invisible class to the field label, we could just use the generated css class. Then the only changes needed is adding a new <select> option, and a css rule.

I'm thinking:

.element-invisible,
.field-label-NEWSTUFF {
  ...
}

This means leaking Field codes out of module containment to the basic core css.

Though if a css preprocessor went in to core, we could use the sass extend-like capability of the developer chosen preprocessor.

Doesn't look like we can change the unfortunate use of "hidden" to indicate the label will not be printed. That key is stored all over the "field_config_instance" database table, and presumably Features|contrib exported Fields :(. I'm curious on how would one deal with changing something (publicly used/distributed) like that.

Everett Zufelt’s picture

What do you think of the approach where the label is required (maybe it already is) and there is an instance setting for formatters and widgets to display the label, by default set to TRUE. If it is set to false (in code or UI) we can use a default implementation of an accessible label. For textfield it would be element-invisible, for checkbox it would be title, for custom fields it would be up to the widget / formatter developer to provide the custom implementation.

leenwebb’s picture

Status: Needs review » Closed (won't fix)

We discussed this at the Montreal Accessibility Sprint and decided that any UI-based solutions would cause more problems than they would solve (primarly due to the confusion that would come with trying to differentiate between words like "hidden", "omitted", and "invisible").

For the use cases where the field label should be hidden for sighted users but available to screen-readers: this can be done at the theming level using any of the standard accessible-invisibility techniques.

leenwebb’s picture

Issue summary: View changes

visible -> invisible is confusing. Changed to printed out in html output -> invisible.