Hola, I’m Hieu, a Software Engineer

The Flutter form cookbook gets you to a working sign-up screen in about forty lines. Then a designer looks at it and you discover that the errors flash before anyone has typed, the Enter key does nothing, the password manager ignores the fields, and on a small phone the keyboard covers the field you are editing. None of those are validation problems. They are the parts of “a form” that the tutorial does not model. The three objects, and what each owns Form is a coordinator, not a layout. It holds a FormState that can validate() , save() and reset() every FormField beneath it in the tree. FormField owns one value, its error string, and whether it has been touched. TextFormField is a FormField wrapped around a TextField . final _formKey = GlobalKey < FormState >(); Form ( key : _formKey, child : Column (children : [ TextFormField ( decoration : const InputDecoration (labelText : 'Email' ), validator : (value) => (...

Turn on TalkBack or VoiceOver in a Flutter app that nobody has thought about, and the experience is usually one of three failures: the screen reader announces “button” with no label, it reads a decorative icon and its text as two separate stops, or it silently skips something the user needs. None of these are visible in a screenshot, which is why they survive so long. The reason they happen is structural. A native Android or iOS app gives the accessibility service a tree of real platform views to inspect. Flutter gives it a canvas. What the screen reader actually reads is the semantics tree — a second tree, built alongside the render tree, that Flutter serialises and hands to the platform. If a piece of information is not in that tree, it does not exist as far as assistive technology is concerned. What the framework gives you for free The good news first: most Material and Cupertino widgets already contribute semantics. Widget What it contribut...