Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sanding UI

blog.jim-nielsen.com

Post reply on HN
Print view View original

11–20 of 414 posts

Re: Sanding UI

#11

Post by oxidant »

lelandfe wrote: post #3
jamamp wrote: post #2

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.

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

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.

Re: Sanding UI

#12

Post by quirino »

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.

Re: Sanding UI

#13

Post by promiseofbeans »

dewey wrote: post #9

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 t…

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.

Re: Sanding UI

#15

Post by extra88 »

dumbo-octopus wrote: post #7
lelandfe wrote: post #6

Earlier quoted context omitted.

The HTML spec doesn't speak much on a11y guidelines. Here's what the W3's WAI says https://www.w3.org/WAI/tutorials/forms/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…

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 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.

Re: Sanding UI

#16

Post by dewey »

promiseofbeans wrote: post #13
dewey wrote: post #9

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 t…

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.

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

Re: Sanding UI

#18

Post by kmoser »

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.

Re: Sanding UI

#19

Post by madeofpalk »

dewey wrote: post #9

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 t…

> 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.

Re: Sanding UI

#20

Post by extra88 »

dewey wrote: post #16
promiseofbeans wrote: post #13

Earlier quoted context omitted.

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.

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

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...

Post reply on HN