```@Composable private fun Subsection(text: String) { Text( modifier = Modifier.semantic...

# compose

[ursus]

@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?

[Zach Klippenstein (he/him) [MOD]]

What would the check validate? How would it know which component you intend to be a header?

[Zach Klippenstein (he/him) [MOD]]

The typography? I’m not sure that’s a strong enough signal in general for a lint check in the material library

[ursus]

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?

[Zach Klippenstein (he/him) [MOD]]

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.

[ursus]

but then how do I specify all of the headline variations? (small, big, etc)
another enum?

[Zach Klippenstein (he/him) [MOD]]

Up to you. You could use an enum, or make three separate components. The latter is more aligned with the Material patterns

[ursus]

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

[Zach Klippenstein (he/him) [MOD]]

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.

[ursus]

right, but there's no way to enforce this in tools - only by humans

other than somehow not exposing MaterialTheme.typography