Live data from Hacker News

Custom JavaScript controls can't capture the nuance of form fields (2021)

drewdevault.com

211–220 of 227 posts

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#211
post #204

Earlier quoted context omitted.

The WAI-ARIA Authoring Practices are not best practices, they are not carefully researched to ensure they can be successfully used in a variety of browsers or with a variety of assistive technologies. They include examples that don't work properly with common browser/screen reader combinations (like Safari + VoiceOver). They'll use ARIA approaches even when they're not the only or best way to achieve a goal. They're…

The open-ui is only potentially good when you need something that resembles the standard controls and interactions. At the moment it only has a few controls specified and if you need anything not covered by those you are going to end up creating your own UI -- e.g. using a treeview dropdown instead of a listbox, or if you have a form with multiple checkboxes and need that group of checkboxes to be a role=select from…

>a form with multiple checkboxes and need that group of checkboxes to be a role=select from an ARIA perspective in order to place form error messages on that group so that screen readers read the error set on the ARIA description, but still display as a list of checkboxes to the user.

ARIA 'select' is an abstract role, it's not meant to be used in code [0]. Form inputs should be grouped by HTML, , and error messages should go where they make sense; the fieldset's is the name of the group but since it is repeated like a description after the name of each child input, it could be useful to add an error message to it.

> If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns

I am saying that, the Authoring Practices examples aren't battle-tested, that's not what they're for. For example, their disclosure widget examples look okay (though in real life at least some of them should be just elements) but their modal dialog example won't reliably keep screen readers from navigating to other parts of the page while it's open.

No one with the resources is willing to create and maintain a library of components, in part because it seems like there's not an 80/20 divide, that it's much more common that people need some variation from whatever is standard (or think they do).

There's https://a11ysupport.io for sharing user-submitted tests but that's simply a record of what individual ARIA attributes and HTML elements work with various assistive technology and browser combinations (without specifying their version numbers).

[0] https://www.w3.org/TR/wai-aria-1.2/#select

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#212
post #150

Earlier quoted context omitted.

Oh yeah I had that recently in a project (IE support required, so no type=number). When you try this, you will eventually find that you use so many keys during normal operation that a whitelist just isn't feasible. Left, right, tab, Home, End, Ctrl+C/V, Shift+Ins, …

Throwing away keys is never the right thing to do anyway. If the user typed 5y8 you don't know if they meant 58 or if the y was meant to be a 6 or 7 so the best thing to do is to have the field contain the full user input and higlight the input as invalid rather than silently guessing what the user meant.

Validate, don't parse ;p

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#213

Earlier quoted context omitted.

this problem was solved around 1986 by Norton Commander and one of the main reasons why two-panel file managers (FAR, mc, TotalCommander) are still in use. When you decouple selection with cursor and make selection "permanent", so you can move around this list without fear to lose accumulated selection, you could pick needed elements one-by-one, sort list by any attributes to simplify selection, apply filters, etc.

Yep. When marking many files for selection the twin-pane file managers let your mind (and your stomach) rest easy. I sometimes use ranger with two or more tabs to similar effect. There was/is a Tcl/TK twin-pane file manager I liked called FileRunner. It's showing it's age now and needs a rewrite -- not for beauty, which I'm not too concerned about, but for some glitches that have crept in with time and lack of mainte…

I'm using FAR in Windows (10 now) every day. I'm using it as my command-lime shell, really, never run cmd or powershell. For everything my console needs (and I'm using a lot of coretools/filetools in the form of mingw64).

I don't know how to live on Windows without it, it is first program I install, even earlier than alternative browser.

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#214
post #193
post #100

Earlier quoted context omitted.

I feel like it's important to establish that "controls should look like the browser intended and not be customizable" is an ideological stance, not an obvious and self-evident truth. And it's one that I strongly disagree with, because it's needlessly controlling: why shouldn't developers me able to make something look however they want? The web is a platform for _all kinds of creations_, not just "website that look a…

I feel like it's important to establish that "controls should look like the Web designer intended and be customizable" is an ideological stance, not an obvious and self-evident truth. And it's one that I strongly disagree with, because it's needlessly controlling: why should Web designers be able to make something look however they want? The web is a platform for _all kinds of users_, not just "websites that look and…

That's just petty, and not effective at making whatever point you're making anyway (which, well, I'm not sure what it is).

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#215
post #160

Earlier quoted context omitted.

Parent is talking about mobile. And on Android it's working rather well I'd say. The only downside I see is that selecting longer spans (shift click) is not possible.

In the context of the parents comment I thought they were comparing that model to others where multi selct exists. I don't think there is a much better model on mobile, except possibly adding a button to each item to select a longer span.

Browser requires very fine degree of dexterity, and has 0 discoverability.

Mobile ones often have a "start multi-select" button in the UI.

Neither is an amazing experience, but IMHO the mobile one is somewhat better.

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#217

As I type into a regular textarea on this site I'm wondering where these textarea replacements on websites are? I'd love for a few examples of this happening. "Many" JS programmers recreate the textarea? Show me.

Facebook, Twitter, Gmail, Discord

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#219

Earlier quoted context omitted.

How about a date range, search fields with dynamic autocomplete, rich content dropdown selects, combined multi selects, etc etc? As I said in my original comment; I agree that where possible normal input elements are preferred, but they do not cover all cases. I guess it depends on what you consider custom, most of those use html form elements underneath, but they definitely require implementing the intricate details…

> How about a date range Two separate date fields? > search fields with dynamic autocomplete a select control with some js to inject the option tags? > rich content dropdown selects I don't even know what this means. Are you just writing code for visual users? > combined multi selects I've never run into an average user who knows how to use multi-selects or how to use the shift/ctrl key to do it. I think checkboxes/r…

These are all pretty poor solutions to the problem. I also prefer native controls but when they don't fit your use case I think it is better to make your own than use non-fitting input types.

I do agree that most users don't know how to use multi-selects though. For that a list with checkboxes works well and allows rich content.

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#220

As I type into a regular textarea on this site I'm wondering where these textarea replacements on websites are? I'd love for a few examples of this happening. "Many" JS programmers recreate the textarea? Show me.

It depends exactly what you mean by textarea. If you need rich text you need something custom. (Although you can use contenteditable as a base)

There are sites like GitHub that slightly enhance a regular textarea (IIRC it is a textarea, haven't thought about it too much)

Post reply on HN