31–40 of 414 posts
The goto tactic for this specific ` ` problem is: Foo
To the author I will add that that radio button is not following the convension of a dot for the selected state instead of a check. Users may think at first sight that multiple/no selection is possible.
On Safari (iPad), type something in the search bar. If you accidentally click outside of your keyboard it will deselect the bar and delete everything you typed. On Spotify the three little dots to do some action to a song have too small of a hitbox. Press even the slightest bit under the button and it will start playing the song. You'd never click there to play the song. When you consider the scale of these apps, the…
If your text remained in place but the control were not focused, what would that control then indicate? In Safari now it _always_ indicates (a) the current page, or (b) your current typing. To do otherwise would be to create a third state: “Used to be typing.” Then it would no longer unambiguously indicate the current state.
Earlier quoted context omitted.
Parent link says NVDA, VoiceOver, and JAWS all support the implicit way. That’s the industry standard suite to support, they’re all free and available across all platforms. If some company makes a shoddy half baked solution for sale (looking at you, Dragon), and they don’t understand basic HTML that has been standardized for years, that’s not my problem. The same way I don’t only use the subset of web technologies th…
Yes, all the screen readers handle implicit labels just fine. As the a11ysupport.io tests show, it's Voice Control software that fails, not just Dragon NaturallySpeaking but also the built-in Voice Control in macOS. I think the implication is these voice control programs aren't using the accessibility tree built by the browser but parsing the DOM themselves, poorly. It's not really surprising for Dragon since it does…
On Safari (iPad), type something in the search bar. If you accidentally click outside of your keyboard it will deselect the bar and delete everything you typed. On Spotify the three little dots to do some action to a song have too small of a hitbox. Press even the slightest bit under the button and it will start playing the song. You'd never click there to play the song. When you consider the scale of these apps, the…
I believe that the iPad behavior you describe is intentional. I’m not sure I’m right here, and there are tradeoffs. I get frustrated with it too. But I think Apple is going for clarity, lack of ambiguity. If your text remained in place but the control were not focused, what would that control then indicate? In Safari now it _always_ indicates (a) the current page, or (b) your current typing. To do otherwise would be…
That being said, I would be fine with an "address bar has been edited but not commited yet" state. It's how most other (desktop?) browsers work and it's not an issue.
This is my strategy in bug bashes, and it generates way more tickets than anyone who has a multidimensional Cartesian matrix of test case combinations. It’s good to know those tests cases to start, but random testing quickly outpaces planned testing when trying to find small issues. Also planned testing is often happy path or expected errors. Sanding like this finds edge bugs much faster.
Earlier quoted context omitted.
UI/UX standards in general are dogshit in most modern software. It's actually baffling how nobody bothers to do even the most basic polishing of their application as the OP. Like they note, clicking around for 10 or 20 minutes would reveal many imperfections, not to mention actually having testers and experiments and any semblance of a scientific design methodology.
I believe it boils down to what we teach as “finished”. Is a feature finished when the code works? When the pull request is merged? Or when a feature works well ? I also believe there’s a lack of care. The difference between a craftsman and anyone else is care .