Thanks Mike, I really appreciate it!

First issue drops December 9th, subscribe to get it delivered to your inbox: eevis.codes/newsletter

#Android #AndroidDev #AndroidAccessibility #InclusiveDesign

But ripple is not just for focus indication, it's also part of the interaction as whole - for example, as feedback from touch input.

The default ripple is so subtle that it's easy to miss, but it's better than nothing.

#Android #AndroidDev #AndroidAccessibility

This can be either just annoying, or purely painful if every keystroke hurts. And if you do this for components on list, it would mean the same happening in every list item - which can mean a lot of extra tab stops.

And with redundant, I mean, for example, adding `clearAndSetSemantics` with content description and not using the contentDescription parameter. And in the wrong place in the modifier chain it also clears everything else.

I would say it depends 😄 those modifiers do add focusability & interaction for assistive tech, but don't consider, e.g, touch target size, so that needs to be added. Also, adding some other modifiers can mess the semantics/interaction, if they're added in wrong place or if they're redundant.

It's also way more maintainable that that hacky solution with an image. Especially when we're talking about back buttons.

(This tip might have something to do with me fixing this kind of solution lately)

Thanks!

And yeah, WearOS (and its accessibility) is definitely something I want to dive deeper into at some point, the size of the WearOS Devices introduces some unique accessibility considerations, which are super interesting.

Thanks!