```@Composable private fun Subsection(text: String...
# compose
u
Copy code
@Composable
private fun Subsection(text: String) {
    Text(
        modifier = Modifier.semantics { heading() }, <------------------
        text = text,
        style = MaterialTheme.typography.headlineSmall,
    )
I need a way to enforce adding
heading()
accesibility semantics for blind people Is there a
Lint check
for this (I'm not seeing one in the stock ones)? Are they maybe coming? But maybe community made ones? Is it hard to create a custom one that does this?
z
What would the check validate? How would it know which component you intend to be a header?
The typography? I’m not sure that’s a strong enough signal in general for a lint check in the material library
u
yes if I say it out loud it's impossible for the stock checks to know that but in practise in my app, it is any
.typography.headlineX
so custom is the only way? is it difficult to do over compose code?
z
I would suggest instead of a lint check just make a Header composable that configured the text and semantics appropriately and use that instead of Text directly.
u
but then how do I specify all of the headline variations? (small, big, etc) another enum?
z
Up to you. You could use an enum, or make three separate components. The latter is more aligned with the Material patterns
u
so like
BigHeader
etc? but then how do I enforce it's usage?
MaerialTheme.typography.headlineSmall
is still public other than harassing people at code review
z
I’d start by writing a small design doc and socializing that with other engineers to get feedback and buy-in collaboratively before executing it. Then if y’all want to move ahead, could send a PSA about it, if you have onboarding docs for using compose at your company make sure they’re updated, and make sure existing code is using it so when people copy/paste for new screens they get the right code.
u
right, but there's no way to enforce this in tools - only by humans other than somehow not exposing
MaterialTheme.typography