Open tony-ditchlabs opened 6 months ago
Hi Tony,
Great suggestion. I understand the feeling when framework is not following these guidelines in some cases. Do you think AccessibilityToolsIgnore
should only ignore tap area checks only or some other issues, too? We need to be very careful with widgets that ignore issues, it gives an easy way to build an app without any accessibility issues by ignoring some of them for being too annoying.
Semantic
widget in the widget treeI can't think of a use case for the font overflows checker (yet)? Or the missing input labels.
The semantics labels I could make a case for - I did wrap at least one widget in ExcludeSemantics
to silence the alerts from this package for a button that just handled some focus logic, but ExcludeSemantics
affects the semantics in all the children of that widget too, so it was probably a bad idea.
I agree that we should discourage the use of a "ignore this package" widget, especially higher in the widget tree, but I still think it should be offered. A couple of use cases I can think of off the top of my head:
@Deprecated
Per the apple accessibilty guidelines, "As a general rule, a button needs a hit region of at least 44x44 pt", which the accessibilty_tools package helps enforce.
However, it's a general rule, not an absolute. There are some widgets from both the Material and Cupertino libraries that bend this rule - like the
CupertinoSlidingSegmentedControl
orshowDatePicker
/showTimePicker
from Material.It would be nice to have a widget included in this package that silences alerts when a child violates accessibility in one manner or another. Something like an
AccessibilityToolsIgnore
that takes a child and several booleans to ignore semantics and/or tap sizes, etc.The workaround for now is to litter the codebase with comments about ignoring the warnings - not ideal.