[HN Gopher] Sanding UI
___________________________________________________________________
Sanding UI
Author : roosgit
Score : 123 points
Date : 2024-09-21 19:36 UTC (3 hours ago)
(HTM) web link (blog.jim-nielsen.com)
(TXT) w3m dump (blog.jim-nielsen.com)
| jamamp wrote:
| I think the article has good sentiments about it. Actually using
| your application a lot helps polish it down a ton.
|
| However, wouldn't putting the input inside of the label (before
| the label text) be a better solution than fiddling too much with
| CSS and flexbox? It's more foolproof to ensure clicks within the
| label activate the input, and eliminates the need for the "for"
| reference.
| lelandfe wrote:
| label>input instead of label+input. This is called an _implicit
| label_ - time was, there were concerns about screen readers
| that couldn 't interpret them.
|
| I don't know how bad that is in practice:
| https://a11ysupport.io/tests/html_label_element_implicit
|
| ...but it does look worse than explicit:
| https://a11ysupport.io/tests/html_label_element_explicit
| swatche wrote:
| The spec says either way
| (https://www.w3.org/TR/html401/interact/forms.html#h-17.9),
| but I agree with putting the input inside the label for the
| acessibility and avoiding the blank space issue.
| lelandfe wrote:
| The HTML spec doesn't speak much on a11y guidelines. Here's
| what the W3's WAI says https://www.w3.org/WAI/tutorials/for
| ms/labels/#associating-l...
|
| > _Whenever possible, use the label element to associate
| text with form elements explicitly_
|
| > [..]
|
| > _In some situations, form controls cannot be labeled
| explicitly... Generally, explicit labels are better
| supported by assistive technology_
|
| ...but people have been saying that for like 15 years now,
| I don 't know how big of a deal those failures are. That'd
| be a good blog post
| dumbo-octopus wrote:
| 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 that the AOL Premium web browser
| supports for $10 bucks a month.
| extra88 wrote:
| 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 hardly anything in a
| browser without its browser extension installed and
| extensions don't have access to the accessibility tree.
| It's more surprising for macOS Voice Control.
| chenmike wrote:
| There's no reason you can't do both, and indeed some a11y
| linters recommend doing that
| oxidant wrote:
| Put the input inside the label and still use "for" on the
| label. No way to test right now but that's what I usually do.
| tshaddox wrote:
| That's what I generally do as well, but sometimes I don't like
| how it leads to empty space that _is_ part of the clickable
| area. This will happen if you have a label tag with the label
| text above the input (and the label text is much narrower than
| the input widget). This isn't a huge problem, but it always
| bugs me.
| philo23 wrote:
| > However, wouldn't putting the input inside of the label
| (before the label text) be a better solution
|
| The one potential downside to doing it the way you describe is
| (assuming the same CSS flexbox layout) now all the white space
| on the _right_ side of the label acts the same as clicking the
| radio /checkbox. Which is almost like the opposite problem to
| the original issue.
|
| This might actually be a good thing for some designs/contexts,
| but not always. For example, on mobile it might lead to miss-
| clicks while trying to scroll past the <label>s
| dexwiz wrote:
| 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.
| fitsumbelay wrote:
| this is the way
| dewey wrote:
| Something for the sanding list: Navigating between
| https://blog.jim-nielsen.com/about/ and https://blog.jim-
| nielsen.com makes the layout shift a bit in Safari on macOS. The
| reason is that Safari only shows the scrollbar when it's needed
| but without "reserving" the space.
|
| I once spent hours debugging this before I realized what was
| happening, my confusion coming from the fact that with the
| inspector open that wasn't the case (As there the scrollbar was
| always visible...).
| promiseofbeans wrote:
| There's a newish CSS feature to fix just this: scrollbar-gutter
| (https://developer.mozilla.org/en-
| US/docs/Web/CSS/scrollbar-g...). Unfortunately, Safari doesn't
| support it.
|
| Can also lead to an ugly gap in your navbar depending on which
| container you're making scroll.
| dewey wrote:
| That sounds promising, for some reason the webkit issue says
| "resolved / fixed" but I don't see any updates in the issue
| itself: https://bugs.webkit.org/show_bug.cgi?id=167335
| extra88 wrote:
| Not everything committed to WebKit ships in Safari.
|
| But the status changed to resolved/fixed only a month ago
| and it's in the latest Safari Technology Preview so maybe
| scrollbar-gutter will ship this year.
|
| https://www.webkit.org/blog/15860/release-notes-for-
| safari-t...
| madeofpalk wrote:
| > The reason is that Safari only shows the scrollbar when it's
| needed but without "reserving" the space.
|
| Every browser with non-floating scrollbars will do this, right?
|
| Safari, in its default configuration on a touch-ish device
| (macbook without a scrollwheel mouse, iOS) don't show explicit
| scroll bar gutters IIRC, and so won't have this problem.
| quirino wrote:
| 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, there must be so much
| combined annoyance.
| dustingetz wrote:
| org chart has been shipped (excel labor cost model actually)
| ivanjermakov wrote:
| I miss this attention to detail in popular websites' UI. Often
| even clicking on the label won't update the form.
| tikkun wrote:
| Is this Jim Neilsen related to Jakob Neilsen (famous UI guy)?
| kmoser wrote:
| My beliefs in the same vein: - If you think
| you've found all the bugs, look again. - If you think
| you've just fixed a bug, test again. - If you think your
| program is done, you're wrong.
| bbor wrote:
| It's kind of a QA tactic in a sense
|
| It's not _kind of_ a QA tactic, this is literally the definition
| of QA. Specifically, this post is about ad-hoc functional
| testing. Kinda funny how this kind of testing used to dominate,
| but in the era of CI /CD, dedicated QA departments, and fancy
| webdriver suites, we've flipped too far the other way, and
| developers need to be reminded to QA their own stuff!
|
| I think we've all learned the hard way that nothing works until
| it's been fixed, no exceptions... no code comes off the dome
| flawless.
| Retr0id wrote:
| oof ouch I just got stabbed by a giant checkmarks-in-radio-
| buttons splinter
| someoneontenet wrote:
| Sounds like op is manually fuzz testing.
___________________________________________________________________
(page generated 2024-09-21 23:00 UTC)