281–290 of 343 posts
Earlier quoted context omitted.
[flagged]
Not everyone who disagrees with you is lying. Accusing people is a bad look here on HN. "Assume good faith" is the standard. You can say "You're wrong". "You're lying", though, is almost never appropriate, and is, in itself, quite hostile.
Earlier quoted context omitted.
What was the auditors' reasoning for that?
That the browser implementations are generally terrible and wouldn't pass accessibility audits, so all browsers would have to change and then some time to pass for the fixed versions to be widespread. We didn't discuss browser-specific issues in detail, but I edited some points in my original message that highlight some of the issues that I suspect make it a no-go for accessibility.
If field validation is "standard HTML" and browsers can't do it in an accessible way, that's squarely a browser problem.
Earlier quoted context omitted.
I never really understood why people want to style stuff like this. I like how you can express yourself by using colors and layout and stuff like that. But at some point usability is more important than branding.
People want to style things to match their page, exactly because consistency is part of usability. Especially given the limitations of browser form validations, you will absolutely need your own validations in addition to any browser validations you use. But your own validations will look different from the browser-provided ones, at least on some browsers. Which will confuse users, hence decreasing usability. And thi…
Earlier quoted context omitted.
That the browser implementations are generally terrible and wouldn't pass accessibility audits, so all browsers would have to change and then some time to pass for the fixed versions to be widespread. We didn't discuss browser-specific issues in detail, but I edited some points in my original message that highlight some of the issues that I suspect make it a no-go for accessibility.
Seems to me that this says that the browsers have the accessibility problems and that's what should be fixed. Why does every website developer have to work around this while the browsers get a free pass? If field validation is "standard HTML" and browsers can't do it in an accessible way, that's squarely a browser problem.
I'll quote my top-level comment:
> This is both bad UX and bad for accessibility (you cannot navigate concatenated strings on the accessibility tree). And this isn't even implementation dependent, it's the spec!
> Not using popups for important information is accessibility 101, but browsers cannot afford to do anything else without interfering with the actual document.
Plus it doesn't matter who's to blame: people with accessibility issues need access now.
Earlier quoted context omitted.
From https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... > Browsers automatically provide validation to ensure that only text that matches the standard format for Internet email addresses is entered into the input box. Browsers use an algorithm equivalent to the following regular expression: > /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0…
It's not the fact that software engineering is broken saddens me as much as the extent . Email is older than absolute majority of active developers and yet, it seems, simple knowledge like "what is email address" remains such an arcane knowledge that you are being looked at weird when present something a tiny little bit more correct than the status quo. Where else can we assume that the common knowledge is flat out w…
Anything you can send an email to that is received, as far as I am concerned. I have my own domain, so why ahould I be forced to add an arbitrarily long string to it to be able to receive the mail? Or exclude @myDomain.com from being input on ?
Or the worst of the worst: Disallow all but a few domains for emails.
At this point, not validating it cient side at all is IMO the correct approach, and instead send a verification email.
My product just failed an accessibility audit because we are using native HTML form validation and the official recommendation was to implement our own validation layer. EDIT: which I agree with. Native HTML validation has many flaws and visual customization is not my biggest concern to be honest (but it's the nail in the coffin). E.g.: - It's impossible to show multiple errors at once per field unless you concat str…
The fact that something provided by the browser can fail accessibility requirements is definitely ironic. We're always taught that the motivation to "use the platform" and "follow semantics and semantic elements" is partly to satisfy the accessibility concerns.
I still think it's worth to leverage the native validation mechanisms.
* You don't have to use the native validity tooltips for the error messages. You can read directly from the input's ValidityState (input.validity) and render the message however you like and show multiple errors if you need to
* The browser can improve and you will benefit from using a standardized approach
The fact that "not using popups" supposedly breaks a11y sounds weird, though. But if you need to respond to an audit then this is the way you can go.
> Errors that do not belong to a particular field
These are indeed interesting! There are techniques to handle those, too. In my project I have a "HiddenValidationInput" component that renders an invisible readonly input that serves the purpose of rendering a custom error that doesn't belong to any other field. It's in fact quite a pleasure to use because you can just conditionally render it.
> The custom validity API is imperative and cumbersome to use
Absolutely agree on this one, and handling this is exactly what my article is about. And I really hope that this part will improve in time, too
Earlier quoted context omitted.
That the browser implementations are generally terrible and wouldn't pass accessibility audits, so all browsers would have to change and then some time to pass for the fixed versions to be widespread. We didn't discuss browser-specific issues in detail, but I edited some points in my original message that highlight some of the issues that I suspect make it a no-go for accessibility.
Seems to me that this says that the browsers have the accessibility problems and that's what should be fixed. Why does every website developer have to work around this while the browsers get a free pass? If field validation is "standard HTML" and browsers can't do it in an accessible way, that's squarely a browser problem.
Here's a simple example that doesn't use React: https://developer.mozilla.org/en-US/docs/Web/API/HTMLObjectE...
I was thinking that it's so weird to talk about using standard HTML validation and then everything is shown with React? If we want to teach people how standard works, we can't assume React as the default.
Earlier quoted context omitted.
> I don't see what difference it makes whether you use some component built into the browser or some component built on top of the browser. And this is why you fail. When you use components built into the browser, everyone gets to benefit from the same years of experience and testing, so that edge cases you have never thought about are handled correctly. Websites that re-implement text boxes, history, scrolling, so m…
> Websites that re-implement text boxes, history, scrolling, so many things, never get every detail right. As browsers continue to give developers more low-level control, the less of a problem this is. Take one of your examples, history. This used to be a high-level feature implemented only by the browser and if you built an SPA your users either had a very bad experience or you had get "clever" with various tricks.…
Quite the opposite, in my experience! As browsers give developers more low-level control, they're more tempted to build half-assed replacements for built-in functionality.
The history API - it's good it exists, mainly because it gives SPA developers a way to solve one of the many intrinsic flaws in the SPA design. On the other hand, it's subject to ridiculous kinds of abuse (stuffing history to make it appear to users that the back button doesn't work), or getting out of sync (because web developers can't manage a stack) and making history unusable.
> The whole idea of an "SPA" was never even imagined by browser makers but developers made that happen.
Yes, with generally terrible results, which could have been avoided if browsers hadn't stagnated.
Earlier quoted context omitted.
Not everyone who disagrees with you is lying. Accusing people is a bad look here on HN. "Assume good faith" is the standard. You can say "You're wrong". "You're lying", though, is almost never appropriate, and is, in itself, quite hostile.
Again “users are too stupid”. That’s remarkably hostile to users and doesn’t belong.
(I see that you edited that bit out of your post, so thanks for listening...)