What?
When users enable LARGE TEXT modes through their device's accessibility settings, this should not compromise the functionality of our apps. It's OK if things are visually less appealing, but the UI shouldn't look broken, and the core functionality must remain intact. See ParentingForLifelongHealth/plh-kids-teens-app-my-content#189 for an example of some issues with elements not fitting on the screen.
How?
This is likely to be an ongoing process of adapting to and designing for these cases. One available tool is to use CSS selectors that target cases where elements have particular widths. An example of this is #3474, however, as noted in #3474 (review), this will not necessarily apply to users on older devices. Generally then, we should be trying to design responsive elements with these extreme scaling limits in mind.
More difficult than styling specific components is handling more complex authored content. For example, the first screenshot in ParentingForLifelongHealth/plh-kids-teens-app-my-content#189 shows a row of buttons at the bottom where the last one overflows the edge of the screen. Ideally, we might have a system whereby the display group row would become a column in certain cases, but it's hard to see how this could be implemented when authors have flexibility in the content and they shouldn't need to be aware of these different layout cases.
It is not possible to recreate the accessibility mode behaviour on web, so an emulator or physical device must be used for testing.
What?
When users enable LARGE TEXT modes through their device's accessibility settings, this should not compromise the functionality of our apps. It's OK if things are visually less appealing, but the UI shouldn't look broken, and the core functionality must remain intact. See ParentingForLifelongHealth/plh-kids-teens-app-my-content#189 for an example of some issues with elements not fitting on the screen.
How?
This is likely to be an ongoing process of adapting to and designing for these cases. One available tool is to use CSS selectors that target cases where elements have particular widths. An example of this is #3474, however, as noted in #3474 (review), this will not necessarily apply to users on older devices. Generally then, we should be trying to design responsive elements with these extreme scaling limits in mind.
More difficult than styling specific components is handling more complex authored content. For example, the first screenshot in ParentingForLifelongHealth/plh-kids-teens-app-my-content#189 shows a row of buttons at the bottom where the last one overflows the edge of the screen. Ideally, we might have a system whereby the display group row would become a column in certain cases, but it's hard to see how this could be implemented when authors have flexibility in the content and they shouldn't need to be aware of these different layout cases.
It is not possible to recreate the accessibility mode behaviour on web, so an emulator or physical device must be used for testing.