Hard to navigate, requires lots of high-precision movement to use well, scales to other form factors terribly. OS consistency, at the limit, is only as good as the OS paradigms, and they are often cast in amber while software marches forward.
-
-
Replying to @slightlylate @_zouhir and
So the web should both reject slavish OS consistency (how much pain have we caused for <button> styling to defend this turf?) as well as the notion that browser provided impls are hallowed. They're just (badly layered) code that happens to be cheap.
1 reply 1 retweet 6 likes -
Replying to @slightlylate @_zouhir and
The real calling is to expose the guts: make all the infra that browsers ship for themselves but not for developers available on equal footing. Open the damned thing up
2 replies 1 retweet 8 likes -
Replying to @slightlylate @_zouhir and
The benefit here, in case it isn't clear, is to undercut the usual arguments against customisation (which are real): that userspace components are bad at a11y, heavyweight, etc. They don't *have* to be, but we force that by keeping <input> a welded-shut disaster
1 reply 1 retweet 5 likes -
agreed - I have a high level doc that goes over this. We're assessing the overall impact and team priorities at the moment, but if we do decide to tackle this I'd value your input. And yes, the story on the web for controls currently sucks, but it doesn't have to :)
2 replies 1 retweet 2 likes -
Replying to @gregwhitworth @slightlylate and
Developer and User Needs: <tabs> element <accordion> element <dialog> element (but good) <tooltip> element <input type="toggle">
2 replies 0 retweets 13 likes -
Replying to @davatron5000 @gregwhitworth and
Have you written up what's not working with <dialog> somewhere?
1 reply 0 retweets 1 like -
Replying to @slightlylate @davatron5000 and
@scottohara has a good writeup here: https://www.scottohara.me/blog/2019/03/05/open-dialog.html …1 reply 0 retweets 4 likes -
Replying to @ericwbailey @davatron5000 and
Some of this sounds fixable by impls, some of it is JAWS/NVDA/TalkBack needing to improve (as the VoiceOver test shows), and most of it is down to other browsers just not implementing. Do I have that right?
2 replies 0 retweets 2 likes -
Replying to @slightlylate @davatron5000 and
My take is browser implementers didn't uphold their end of the bargain, and AT trying to figure out to best respond to varying, half-baked support.
1 reply 0 retweets 2 likes
Huh? If VoiceOver can use our AT tree to read out the right stuff, so can other a11y tools.
Maybe @sundress knows more?
-
-
Replying to @slightlylate @ericwbailey and
VoiceOver "reads out the right stuff" is relative to the situation. certain content is completely ignored if the nesting levels go to deep (e.g. lists) none of the semantics of the content is announced, and depending on the length of the content is can be far too much to take in
1 reply 0 retweets 1 like -
Replying to @scottohara @slightlylate and
Scott O'MG Retweeted Steve Faulkner
that said, i agree with your original statement that there are issues that implementation, and AT both need to work through here. Though
@stevefaulkner's tweet about the linked issue would be one way forward to smooth out some of these issues:https://twitter.com/stevefaulkner/status/1117853252333162496 …Scott O'MG added,
2 replies 0 retweets 1 like - 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.