Just updated the tests.
As I never used XPath before, I would be happy if somebody would validate my query – as it just badly copy & pasted together.

Also the test about the form in the label doesn't make sense in the horizontal form anymore. As the test is inherited from the base test class however, I need to overwrite the method. Didn't want to us markTestSkipped, as it unnecessarily displays a warning, while everything is actually okay here. 😃

@Nyholm as you added this in #24435 or at least proposed it, I would ask how we should fix the rendering issues?

Is just the ordering of label -> errors -> input (-> help) important? If this is the case, we could add the errors above the widget (and the user could reorder the with CSS flex + order.
But rendering the label inside the label with width < 200px looks a bit broken.

wdyt?

An alternative would be to just add another block

{% block form_row -%}
    {%- if expanded is defined and expanded -%}
        {{ block('fieldset_form_row') }}
    {%- else -%}
        {%- set widget_attr = {} -%}
        {%- if help is not empty -%}
            {%- set widget_attr = {attr: {'aria-describedby': id ~"_help"}} -%}
        {%- endif -%}
        <div class="form-group row{% if (not compound or force_error|default(false)) and not valid %} is-invalid{% endif %}">
            {{- form_label(form) -}}
            <div class="{{ block('form_group_class') }}">
                {{- form_widget(form, widget_attr) -}}
                {%- block form_widget_errors "" -%} {# <-- here! #}
                {{- form_help(form) -}}
            </div>
            {##}</div>
    {%- endif -%}
{%- endblock form_row %}

So that a user can just do this in his/her own theme:

{% extends "bootstrap_4_horizontal_layout.html.twig" %}

{# hide label errors and display them in the widget #}
{%- block form_label_errors "" -%}
{%- block form_widget_errors -%}
    {{- form_errors(form) -}}
{%- endblock -%}

(or we combine both solutions and add the block above the {{ form_widget() }} call and the user has to reorder them, if the ordering should be widget -> errors

Travis failure is the issue, that 7.1 and 7.2 pull in a more recent version of the twig bridge, which doesn't have this change. This needs to be merged up, then this is automatically fixed.

@apfelbox For the deps=high job that's true. But we need to bump some dependencies for the deps=low job.

Status: Needs work

@xabbuh okay, so what do I need to do here? I am not sure on where I should bump the dependencies.

Looks like you can apply the same changes to composer.json as in #27886.

@xabbuh after rebasing I realised, that as #27886 was now already merged, my branch should now include the changes in the composer.json.

See here: https://github.com/symfony/symfony/blob/040df30bbc655006828044cc3dab377cfc5156a9/src/Symfony/Bridge/Twig/composer.json

Tests still fail though and I have now idea why.
I see that composer installs the form component, but apparently the wrong one.

As I am not familiar with how the tests work here I am not quite sure whether the test script is able to automatically install my changed dependencies.

Any help appreciated, I didn't do a cross-component PR before. 😅

Travis failure is unrelated as some compilation crashed. Can I restart the travis build?

wasn't this rendered in the label for accessibility reasons ?

@stof yep, I linked that above. That's why I would like to wait for the feedback from @Nyholm, because he made these changes and I don't want to introduce a regression here.
I also proposed an alternative solution in the comments above, which might be a good middle ground (but would require additional effort of the app developer, as (s)he would need to add a short custom form theme).

@Nyholm Do you have time to review this one? Would be great. Thanks.

(rebase needed)

I'll review this PR this week. Sorry for the delay.

According to:

http://blog.ricardofilipe.com/post/aria-describedby
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute

It is possible. But I am not an expert 😛

Any progress on this one?

Hey. Sorry for the delay. I've finally had a sit down with an accessibility expert.

She said that it is always recommended to have the error message inside the label. A solution here would be to put the <input> inside the label as well. I know, it is weird, but that is allowed and works for most users.

I tried to argue for a different solution. The second best was to use labelled-by on the input to refer to the error message. This is only a okey solution. It is allowed by WCAG, but not optimal. It is because the support for WAI-AREA in assistive devices and browsers varies a lot and should not be trusted.

Could you see if you can update this PR to be more accessible? Now when I know the rules it is easier for me to review this PR.

@Nyholm it seems that horizontal layout is still broken (I stumbled upon this one myself).

IMHO maybe we should make it compatible with bootstrap first and then apply some sort of recommendation in the docs informing about this. For me, accessibility provided by bootstrap is very good.

@apfelbox @Nyholm How can we move forward on this pull request?

@fabpot as @Nyholm noted, I could implement the labelled-by solution, so that we can keep using the "old" layout while having okay-ish accessibility.

This is a compromise, that should work for both sides, I guess.

I would implement it in a way, that you can override this behaviour by just overwriting two blocks. This is like my suggestion in #27892 (comment) so that you have two blocks with possible positions of the error label, and by default one is empty and the other one is filled (but you could change it by extending the template and reversing the positions).

@apfelbox I'm ok with your solution, but I'm no accessibility expert. @Nyholm I suggest that we implement what @apfelbox suggests if you you think this is the "best" compromise.

Thank you for this PR. I like that you addressed the issue but we also need to consider accessibility.

I suggest closing this PR and solve it like described here: #28086 (comment)

I would be more than happy to review a new PR form you.

#eu-fossa