Highlight vertical tabs when they have elements with errors

The error ("Path already exists") while entering no path at all will be fixed by #606888: Node creation breaks if no path is specified.

I couldn't find this either. I searched for the string "Optionally specify an alternative URL" and nothing was found. Odd.

So there are two fixes here:

1) Re-order the vertical tabs (shown in http://drupal.org/files/issues/vt-defaulttabs.png)
2) Ensure errors are highlighted on the vertical tabs (should this be a separate issue?)

Wow, title and screenshots in this issue were very confusing. Please don't just snap part of your screen and assume I can tell what's going on. Please snap the whole screen and articulate with drawing or arrows or something. Impossible to see the whole context with several different screenshots of the same thing.

Subscribe.

Heres the patch I wrote for the backport of Vertical Tabs in contrib with a screenshot.

I've applied the patch in #9 to the Vertical Tabs backport for Drupal 6.

subscribing, going to see what I can help here.

Looking onto this, it seems the form element to which the error applies isn't given an error class in Drupal 7:
<input type="text" maxlength="255" name="path[alias]" id="edit-path-alias" size="60" value="example" class="form-text">

In Drupal 6 it would look like this:
<input type="text" maxlength="128" name="path" id="edit-path" size="60" value="about-us" class="form-text error">

Surely that's wrong? I've searched the issue queue but not found mention of it elsewhere.
We'd need this class to be able to highlight it. Assuming we don't go the JS-only route.

Where does this stand now -- do we have a usability feature in D6 vertical tabs that's not yet in D7?

@Dave can you supply a patch for this in D7 and Seven?

Would #1155138: Flag tabs containing elements that failed form validation be of any help to patch this? The solution for horizontal tabs is a pure javascript solution and as the (js) code for vertical and horizontal tabs is amazingly similar... It was the module owner who implemented it, so the patch is in git: http://drupalcode.org/project/field_group.git/commit/acf7bdf. Code from above mentioned issue has been tested by me and works perfect.

Note that using the error class to style tabs is left to themers, so no css is added to the module to try to give tabs containing errors special appearance.

That's true. I would indeed appreciate some feedback on the solution chosen.
I must say, when field group is enabled, the javascript hook exists for the vertical tabs too within field_group.
- Edit - removed code. Did not make sense to post that here.

This patch lets get the tab buttons red borders when they contain erroneous form elements.

This is working well for me, however we need the CSS in Sevens version of vertical-tabs.css also.

I think that changes to css in specific themes should be separate issues, 1 per theme. This is about the code that makes it possible for themes to do something with it. Thus, IMO we shouldn't stall this patch for core code to wait for accompanying changes to Seven, Bartik, or whatever theme.

Back to needs review?

To ensure that this solution is accessible to all we are going to need to do more than add a class, we need to convey the error in a textual / discoverable way.

I'm not sure what we can do to convey this in a textual and discoverable way, but am happy to test proposed solutions.

@22, don't agree, Seven is our core default admin theme and it should work for Seven right away, it mostly does but the tab highlight does not, so if two tabs are affected you will only know about one of them. Its a two line addition to the patch. As the maintainer of the Seven theme the last thing I want is two line CSS patches hanging around for Dries and Webchick to review that could go in now - they have better more important things to do.

@23, good point but should not hold this up going in now. This is major usability issue for 95% of users or more and this patch can fix it very easily. Accessibility issues can be a follow up and we both know that it will take a long time to find a solution - fix it for the 95% now in Drupal 7. Craft a really solid solution for D8 and backport it.

Completely disagree w/ 24. Isn't the purpose of gates that we don't leave things hanging around? I mean seriously what is the purpose of gates if we just ignore them when they are inconvenient?

Everett, the gates are for Drupal 8, this is Drupal 7, which the gates have nothing to do with, and committing this now does not hurt anyone at all, but helps all those who are sighted - the otherwise impaired but not blind included.

The "well crafted solution" is under way at #447816: WCAG violation: Relying on a color by itself to indicate a field validation error and is indeed marked D8, that issue has been open for nearly 2.5 years, and looks no closer to a real solution than it did a year ago. At least this allows us to give most users a decent experience until such time as the real fix can be back-ported, which could easily be another year or more.

Moving this to D8. I do think we should check to see if this is done there.

Re-rolling in Drupal 8.

#28: add-erroro-higlighting-within-vertical-tabs-28.patch queued for re-testing.

tagging

It appears that in both native D8 themes, bartik and seven, the vertical tabs are handling the error reporting properly now.

The tab with the error is "opened" by default and the appropriate message is being show. One accessibility enhancement may be to provide the name of the alias already in use in the error message, but I don't feel that falls under this issue.

Additionally, there is a CSS issue in the Bartik theme when rendering the tabs, at least in Firefox so far. Again, I believe this deserves to be a separate issue in itself.

I will cross check the compatibility of the styles are report additional issues if needed.

I didn't change any code to fix this issue. Likely the result from twig integration and UI refinement. Changing status to closed.