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:
visibleprinted out in html output- above
- inline
- hidden
hiddenomitted
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
Comment | File | Size | Author |
---|---|---|---|
#14 | expose-field-labels-visibility-1361102-4.patch | 2.94 KB | mgifford |
#4 | expose-field-labels-visibility-1361102-3.patch | 3.28 KB | Alex Komm |
Comments
Comment #1
Everett Zufelt CreditAttribution: Everett Zufelt commentedThis 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.
Comment #2
Bojhan CreditAttribution: Bojhan commentedYhea, 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
Comment #3
dozymoe CreditAttribution: dozymoe commentedAdded 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:
I think the options for #title_display are:
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.
Comment #4
Alex Komm CreditAttribution: Alex Komm commentedFirst attempt
Comment #5
Everett Zufelt CreditAttribution: Everett Zufelt commentedComment #6
bowersox CreditAttribution: bowersox commentedCan 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!
Comment #7
Everett Zufelt CreditAttribution: Everett Zufelt commentedYup, all patches are first written against 8.x, then considered for backport.
Comment #8
Everett Zufelt CreditAttribution: Everett Zufelt commented#4: expose-field-labels-visibility-1361102-3.patch queued for re-testing.
Comment #10
dozymoe CreditAttribution: dozymoe commented@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.
Comment #11
dozymoe CreditAttribution: dozymoe commentedAlso 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.
Comment #12
Everett Zufelt CreditAttribution: Everett Zufelt commented@dozymoe
There is currently no automated JS testing of Core.
Comment #13
mgifford@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
Comment #14
mgiffordJust moving the patch forward.
Comment #15
dozymoe CreditAttribution: dozymoe commentedInstead 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:
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.
Comment #16
Everett Zufelt CreditAttribution: Everett Zufelt commentedWhat 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.
Comment #17
leenwebb CreditAttribution: leenwebb commentedWe 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.
Comment #17.0
leenwebb CreditAttribution: leenwebb commentedvisible -> invisible is confusing. Changed to printed out in html output -> invisible.