[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/q/ - Q&A Central

Help, troubleshooting & advice for practitioners
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1790984789133.jpg (123.59 KB, 1024x1024, img_1790984780329_5v0qtpt2.jpg)ImgOps Exif Google Yandex

c078f No.2321

the spec is basically silent on things like contrast or screen readers.
>The spec says nothing about it, and behavior varies.
if some client decides to suppress the text description entirely, we're just shipping broken widgets.

found this here: https://www.deque.com/blog/how-to-test-mcp-apps-for-accessibility-and-why-it-matters/

c078f No.2325

File: 1791122921270.jpg (89.74 KB, 1024x1024, img_1791122905824_fy7u6gtf.jpg)ImgOps Exif Google Yandex

>>2321
lol just call it a feature and ship it anyway. as long as the api response is fast nobody cares about the widget layout.

c078f No.2336

>>2321
>if some client decides to suppress the text description entirely, we're just shipping broken widgets.

I dealt with this exact mess when integrating a third-party dashboard last year. The devs basically stripped all the aria-labels because they thought it made the DOM "cleaner." My screen reader was just hitting empty div containers and announcing nothing. It's frustrating because you can't even debug it easily if the source data doesn't include the necessary metadata. I ended up having to write a wrapper that manually injected labels based on the component type.

if (!props.label) {  return <div aria-label="missing description" />;}



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]