I would have thought this might break more tests (internal or Google/customer), but it looks like it's good. I guess fewer people are using M3.

Let's see if someone ask for a revert in the coming days 🤞

A reason for requesting a revert of flutter/flutter/145087 could
not be found or the reason was not properly formatted. Begin a comment with 'Reason for revert:' to tell the bot why
this issue is being reverted.

Reason for revert: failing on accessibility checks b/329548765

@justinmc
I would says that it is weird that reducing the gap below the container by 4.0 (as done by this PR) changes wether the TextField meet the accessibility guideline or not (the interactive zone is the same so it was probably wrong before too).

In either case, this should be fixed, if you have a screenshot or access to this TextField configuration, it would be interesting to know its configuration (maybe isDense is set to true?).

I have not yet migrated tests related to isDense (one difficulty is that it is no more a thing in M3, so we will have to decide how it impacts rendering). I can focus on such test before relanding this change.

@justinmc
I checked the InputDecorator implementation.
It is intended that the min size is lower than kMinInteractiveDimension in some cases:

@bleroux Looking into this more, it seems like it's not the minimum size that it's breaking, it's the MinimumTextContrastGuideline! Very strange. A field with red error text underneath is now breaking this guideline.

The only hunch I have is this line:

It inflates the bounds by 4 pixels. Maybe that's now enough to overlap with the bottom of the field, so it's "seeing" some additional color that it wasn't before?

The only difference that I see before and after your change is that paintBoundsWithOffset is shifted up by 4 pixels (which is exactly the difference that I'd expect from this PR).

@justinmc Very interesting findings.
I have not yet figured out how to reproduce this failure. I would be interested in having more information (error message, screenshot, etc).

It's throwing here:

I'll try to get some help on the accessibility test, and otherwise I'll try to write a test that reproduces it and post back.

Sorry for the silence here. I haven't been able to track down any help on the accessibility guideline stuff. I did try to create a test that reproduces the failure, but I wasn't able to get it to fail on this branch. Something similar to the below with a few tweaks must do it...

  testWidgets('text contrast bug', (WidgetTester tester) async {
    TextFormField getFormField({
      required String labelText,
    }) {
      return TextFormField(
        keyboardType: TextInputType.number,
        validator: (String? value) {
          return 'Please enter $labelText';
        },
        decoration: InputDecoration(
          labelText: labelText,
          filled: true,
          errorStyle: const TextStyle(
            fontSize: 16.0,
          ),
        ),
      );
    }
    final SemanticsHandle handle = tester.ensureSemantics();
    final GlobalKey formKey = GlobalKey();
    await tester.pumpWidget(MaterialApp(
      home: Scaffold(
        body: Center(
          child: Form(
            key: formKey,
            child: Column(
              children: <Widget>[
                getFormField(
                  labelText: 'Deeeeeeee ID',
                ),
                const SizedBox(
                  height: 16,
                ),
                getFormField(
                  labelText: 'Buuuuuuuu ID',
                ),
                const SizedBox(
                  height: 40,
                ),
                Container(
                  width: double.infinity,
                  padding: const EdgeInsetsDirectional.symmetric(horizontal: 8.0),
                  child: FilledButton(
                    onPressed: () {
                      final FormState formState = formKey.currentState! as FormState;
                      if (!formState.validate()) {
                        return;
                      }
                    },
                    child: const Text('Immmmmmmmmm'),
                  ),
                ),
              ],
            ),
          ),
        ),
      ),
    ));

    await tester.pumpAndSettle();

    await tester.tap(find.byType(FilledButton));
    await tester.pumpAndSettle();

    await expectLater(tester, meetsGuideline(const MinimumTextContrastGuideline()));

    handle.dispose();
  });

@justinmc Thanks for providing this example. 🙏
I see that the background color is set for helperStyle, I will try various combination, but I'm not sure it is related because in #145087 (comment) you mentionned that it was related to the error message (I will tweak errorStyle too).

In the meantime, while playing with this test, I can make it fails by using obviously wrong colors (in this case it fails even without using this branch). Looking at the error message I see that it gives a clue to which text is involved and which colors, it might help us to repro if we can see the error message from the failing customer test.

Here is an example of the error message for a test that fails on the text contrast guideline :

   Which: SemanticsNode#5(Rect.fromLTRB(12.0, 64.0, 86.4, 80.0), label: "helper", textDirection:
ltr):
          Expected contrast ratio of at least 4.5 but found 1.94 for a font size of 12.0.
          The computed colors was:
          light - Color(0xfffef7ff), dark - Color(0xffffa000)
          See also: https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html

          SemanticsNode#7(Rect.fromLTRB(12.0, 64.0, 86.4, 80.0), label: "helper", textDirection:

Updated my previous comment with improvements to the test code, but it still doesn't fail.

I thought it might be checking the contrast during the time that the text color is animating to the error state, but that didn't seem to be it with a quick attempt. I'll keep investigating.

@justinmc
#146507 might be related to the failure.
As you rightly pointed:
"the accessibility test inflates the bounds by 4 pixels. Maybe that's now enough to overlap with the bottom of the field, so it's "seeing" some additional color that it wasn't before?"
So yes, for a filled text field, a 1 pixel red line will be inside the area and wasn't before my PR.
I will file a PR for #146507 tomorrow, it might break internal tests if they rely on golden. But if we can land it, I will be eager to see if it helps here.