8 ms·

so there is a good reason for this - I've learned the hard way that you cannot trust the number input, it has some very strange behavior. I could write a blog p

so there is a good reason for this - I've learned the hard way that you cannot trust the number input, it has some very strange behavior. I could write a blog post just about that issue. I plan to create my own custom number input that has its own increment/decrement buttons. The thing was built with react and the number input has some unanticipated side effects.

azemetre 4y ago
It may be worth mentioning in a future blog post because you lose a lot of the built in behavior of browser input when you make everything a "text" input. It hurts accessibility and inclusiveness as well by ignoring these common browser behaviors.
- padseeker 4y ago
  That's fair, I might have to revisit the number input issue. I totally get your complaint. Experimenting with the number input was a learning experience. I built Keenforms with React, and both React and Angular have some strange behaviors related to number inputs.
  - radiojasper 4y ago
    As a web designer with a speciality in a11y, it hurts that you deemed this not important enough to find the true cause of your issue with the number input. I hope you can revisit this in a future update!
    - padseeker 4y ago
      I'll see what I can do, but HONESTLY the number input has issues. I should write an article about it. I get what you are saying. However sometimes you have to circumvent the limitations of the browser to get it to do what you want it to. Or you have to write a ridiculous amount of code to compensate for that problem. It still accepts number values. I made a decision based on the problems I was having, I can revisit it and rectify it IF ITS POSSIBLE while maintaining existing functionality.
    - dingleberry420 4y ago
      https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...
      - peterangular 4y ago
        Linking that article from 2020 is problematic - please read my response here: https://news.ycombinator.com/item?id=32141468 https://news.ycombinator.com/item?id=32141468
        padseeker 4y ago
        So I started writing code for this back in 2017, and I discovered a lot of issues with the number input back in 2019 so I never revisited it. So I'm glad certain issues have been resolved, but there are still others. I could probably write an article just about why the number input is terrible.
        peterangular 4y ago
        > I could probably write an article just about why the number input is terrible. And, with as many people are saying outright "don't use numeric inputs" I would very much want to understand what issues you encountered, when, and, on what platform. Otherwise it sorta feels like FUD in 2022 to push against numeric inputs without specifying the actual issues. In other words, please do write an article. Although I'm skeptical, I would read it with an open mind + in good faith.
        padseeker 4y ago
        Hey I just wrote a blog post of why the number input is terrible; https://blog.keenforms.com/why-the-number-input-is-the-worst-input/ https://blog.keenforms.com/why-the-number-input-is-the-worst... I also shared it on hacker news. I hope this helps.
    - thaumasiotes 4y ago
      > As a web designer with a speciality in a11y This is hard to believe - as I remark above, the accessibility issues with the number input type are extreme. It's much, much worse than any alternative, including a plain text input type. `<input type="number">` is something that might be recommended blindly on the basis of a checklist, but not something that might be recommended by anyone familiar with relevant concepts.
      - peterangular 4y ago
        > > As a web designer with a speciality in a11y > This is hard to believe Oof. Even if they're outright wrong they could still have lots of experience with accessibility. On HN we typically assume good faith even when we disagree with each other. That being said, I agree with them. The arguments made against the "numeric" field here are out of date, and not something I have ever ran into with my own testing. I'm not claiming there are no quirks, or issues... but I find it so weird that everyone is throwing modern accessibility under the bus here for what seems to be edge cases... from 2020. > `<input type="number">` is something that might be recommended blindly on the basis of a checklist, but not something that might be recommended by anyone familiar with relevant concepts. Can you please provide sources why it is not recommended to use numeric input types? I've read the .gov.uk article and it's from 2020 and many of the issues are resolved in the years since it came out.
        deleted 4y ago
        [deleted]
        thaumasiotes 4y ago
        > I've read the .gov.uk article and it's from 2020 and many of the issues are resolved in the years since it came out. > please read my response here: https://news.ycombinator.com/item?id=32141468 https://news.ycombinator.com/item?id=32141468 Reading that response was a surreal experience. "Many of the issues are resolved since it came out"... except for the important ones? Here are the issues you rebutted: - A number input blocks dictation and selection when using Dragon Naturally Speaking - number inputs appear unlabeled in NVDA's element list - plus, they look weird in NVDA's object navigation - and they're unlabeled when using nvda+tab But you appear to have confused the article section titled "Accessibility" with the concept of accessibility. Here are some accessibility issues, also mentioned in the article, that you didn't bother to address: - Values in a number input are automatically rounded or even converted to exponential notation by the browser. Because while it might look like your credit card number is 4000 0566 5566 5556, what you want to put into the form is 4.000056655665556e+15. - Safari 5.1 inserts commas into "number"s with at least 16 digits. (Yep, Safari 5.1 is old. It was also old in 2020. Doesn't make this less of a disaster for users on Safari 5.1.) - Values within a number input change at random if the user's mouse has a mouse wheel. Between the issues that have been fixed, and the issues that haven't been fixed... which ones sound like they're worse problems? Imagine this changelog: 1. NVDA now has better visibility into number input elements. 2. number input elements still don't work. > The arguments made against the "numeric" field here are out of date, and not something I have ever ran into with my own testing. You need to do some real testing. It's not hard to run into the mousewheel issue. I've run into it on multiple occasions. It is not necessary to dispatch mouse events to child elements - anyone who clicks on the input element to focus there has now positioned their cursor directly over the input element.
- sevenf0ur 4y ago
  GOV.UK found that type=number actually hurts accessibility and is riddled with usability problems: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...
  - peterangular 4y ago
    Article from 2020... many of these issues are no longer a thing and/or are just really weird to call out. From their accessibility bullets: > cannot be dictated or selected when using Dragon Naturally Speaking Isn't this just a speech-to-text engine? I can say that I haven't ran into anyone using this for web control in my entire career. I'm certain it has an accessibility use-case and all, but I haven't ran into a practical example. I'm very apt to write this off as "moot," and would also suspect it may have been addressed since 2020. Does anyone here use Dragon Naturally Speaking for web control? Good faith real question. > appears as unlabeled in NVDA's element list Fixed - https://github.com/alphagov/reported-bugs/issues/41#issuecomment-663881795 https://github.com/alphagov/reported-bugs/issues/41#issuecom... > appears as a spin button in NVDA's object navigation, which has an edit field and two buttons inside - those buttons are unlabeled, but decrease/increase the value Fixed - https://github.com/nvaccess/nvda/issues/9675#issuecomment-592997952 https://github.com/nvaccess/nvda/issues/9675#issuecomment-59... > is reported as unlabeled edit field when using nvda+tab Fixed - https://github.com/nvaccess/nvda/issues/9675#issuecomment-592997952 https://github.com/nvaccess/nvda/issues/9675#issuecomment-59... --- I want to point out that this article is out of date and basing any sort of modern FE development decisions on it merits much more research than just "GOV.UK tried it and it hurts accessibility" ... I attest that not using the correct input type on fields is more of an accessibility issue - especially numeric fields.
inetknght 4y ago
> I plan to create my own custom number input that has its own increment/decrement buttons. How will you handle users who have javascript disabled? Why reinvent the wheel? Why not fix whatever problem you have with numeric input?
- padseeker 4y ago
  The whole thing WILL NOT WORK without javascript. The rules engine runs in the browser, which is why you get that instant feedback loop. Admittedly keenforms isn't for EVERYONE. There are built from scratch forms that use React or Angular or Javascript that provides instant feedback. Its not impossible to forgo JS but its hard to create a better UX with the instant feedback that only javascript can provide.
  - easrng 4y ago
    Plain HTML can do validation with regexes (pattern attribute) and the required attribute.
- geraldwhen 4y ago
  If you want masking, and you DON’T want spinners, text makes just as much sense. Think a currency input, or SSN, or zip code field. You almost never actually want the functionality of an html number input.
- peterangular 4y ago
  > How will you handle users who have javascript disabled? They won't/can't. Their only real options are to fallback to either the "text" field or the "numeric" field. > Why reinvent the wheel? Why not fix whatever problem you have with numeric input? JS devs will prioritize chasing after their ideal UIX long before they consider things like JS being disabled, screen readers, ARIA tags, cross-platform compatibility, etc. There's countless replacements for long-supported HTML input fields that still get active development: date pickers, numeric inputs, sliders, you name it. If it exists in the base W3C spec someone has likely reinvented the wheel for every purpose from pixel-perfect skeuomorphism, to aggressive input masking, to "instant feedback," to vaguely claiming "you cannot trust the number input" - the list goes on and on. --- OP if you're reading this - I hope you're considering JS being disabled (graceful + functional fallbacks), ARIA, aggressive cross-platform testing, and testing with real screen readers. If you aren't, this is not an accessible service.
operator-name 4y ago
The UK Government design team have a blog post on this: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des... > Avoid using inputs with a type of number > Do not use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong. (https://design-system.service.gov.uk/components/text-input/#numbers https://design-system.service.gov.uk/components/text-input/#...)

azemetre 4y ago

It may be worth mentioning in a future blog post because you lose a lot of the built in behavior of browser input when you make everything a "text" input. It hurts accessibility and inclusiveness as well by ignoring these common browser behaviors.

padseeker 4y ago
That's fair, I might have to revisit the number input issue. I totally get your complaint. Experimenting with the number input was a learning experience. I built Keenforms with React, and both React and Angular have some strange behaviors related to number inputs.
- radiojasper 4y ago
  As a web designer with a speciality in a11y, it hurts that you deemed this not important enough to find the true cause of your issue with the number input. I hope you can revisit this in a future update!
  - padseeker 4y ago
    I'll see what I can do, but HONESTLY the number input has issues. I should write an article about it. I get what you are saying. However sometimes you have to circumvent the limitations of the browser to get it to do what you want it to. Or you have to write a ridiculous amount of code to compensate for that problem. It still accepts number values. I made a decision based on the problems I was having, I can revisit it and rectify it IF ITS POSSIBLE while maintaining existing functionality.
  - dingleberry420 4y ago
    https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...
    - peterangular 4y ago
      Linking that article from 2020 is problematic - please read my response here: https://news.ycombinator.com/item?id=32141468 https://news.ycombinator.com/item?id=32141468
      - padseeker 4y ago
        So I started writing code for this back in 2017, and I discovered a lot of issues with the number input back in 2019 so I never revisited it. So I'm glad certain issues have been resolved, but there are still others. I could probably write an article just about why the number input is terrible.
        peterangular 4y ago
        > I could probably write an article just about why the number input is terrible. And, with as many people are saying outright "don't use numeric inputs" I would very much want to understand what issues you encountered, when, and, on what platform. Otherwise it sorta feels like FUD in 2022 to push against numeric inputs without specifying the actual issues. In other words, please do write an article. Although I'm skeptical, I would read it with an open mind + in good faith.
        padseeker 4y ago
        Hey I just wrote a blog post of why the number input is terrible; https://blog.keenforms.com/why-the-number-input-is-the-worst-input/ https://blog.keenforms.com/why-the-number-input-is-the-worst... I also shared it on hacker news. I hope this helps.
  - thaumasiotes 4y ago
    > As a web designer with a speciality in a11y This is hard to believe - as I remark above, the accessibility issues with the number input type are extreme. It's much, much worse than any alternative, including a plain text input type. `<input type="number">` is something that might be recommended blindly on the basis of a checklist, but not something that might be recommended by anyone familiar with relevant concepts.
    - peterangular 4y ago
      > > As a web designer with a speciality in a11y > This is hard to believe Oof. Even if they're outright wrong they could still have lots of experience with accessibility. On HN we typically assume good faith even when we disagree with each other. That being said, I agree with them. The arguments made against the "numeric" field here are out of date, and not something I have ever ran into with my own testing. I'm not claiming there are no quirks, or issues... but I find it so weird that everyone is throwing modern accessibility under the bus here for what seems to be edge cases... from 2020. > `<input type="number">` is something that might be recommended blindly on the basis of a checklist, but not something that might be recommended by anyone familiar with relevant concepts. Can you please provide sources why it is not recommended to use numeric input types? I've read the .gov.uk article and it's from 2020 and many of the issues are resolved in the years since it came out.
      - deleted 4y ago
        [deleted]
      - thaumasiotes 4y ago
        > I've read the .gov.uk article and it's from 2020 and many of the issues are resolved in the years since it came out. > please read my response here: https://news.ycombinator.com/item?id=32141468 https://news.ycombinator.com/item?id=32141468 Reading that response was a surreal experience. "Many of the issues are resolved since it came out"... except for the important ones? Here are the issues you rebutted: - A number input blocks dictation and selection when using Dragon Naturally Speaking - number inputs appear unlabeled in NVDA's element list - plus, they look weird in NVDA's object navigation - and they're unlabeled when using nvda+tab But you appear to have confused the article section titled "Accessibility" with the concept of accessibility. Here are some accessibility issues, also mentioned in the article, that you didn't bother to address: - Values in a number input are automatically rounded or even converted to exponential notation by the browser. Because while it might look like your credit card number is 4000 0566 5566 5556, what you want to put into the form is 4.000056655665556e+15. - Safari 5.1 inserts commas into "number"s with at least 16 digits. (Yep, Safari 5.1 is old. It was also old in 2020. Doesn't make this less of a disaster for users on Safari 5.1.) - Values within a number input change at random if the user's mouse has a mouse wheel. Between the issues that have been fixed, and the issues that haven't been fixed... which ones sound like they're worse problems? Imagine this changelog: 1. NVDA now has better visibility into number input elements. 2. number input elements still don't work. > The arguments made against the "numeric" field here are out of date, and not something I have ever ran into with my own testing. You need to do some real testing. It's not hard to run into the mousewheel issue. I've run into it on multiple occasions. It is not necessary to dispatch mouse events to child elements - anyone who clicks on the input element to focus there has now positioned their cursor directly over the input element.
sevenf0ur 4y ago
GOV.UK found that type=number actually hurts accessibility and is riddled with usability problems: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...
- peterangular 4y ago
  Article from 2020... many of these issues are no longer a thing and/or are just really weird to call out. From their accessibility bullets: > cannot be dictated or selected when using Dragon Naturally Speaking Isn't this just a speech-to-text engine? I can say that I haven't ran into anyone using this for web control in my entire career. I'm certain it has an accessibility use-case and all, but I haven't ran into a practical example. I'm very apt to write this off as "moot," and would also suspect it may have been addressed since 2020. Does anyone here use Dragon Naturally Speaking for web control? Good faith real question. > appears as unlabeled in NVDA's element list Fixed - https://github.com/alphagov/reported-bugs/issues/41#issuecomment-663881795 https://github.com/alphagov/reported-bugs/issues/41#issuecom... > appears as a spin button in NVDA's object navigation, which has an edit field and two buttons inside - those buttons are unlabeled, but decrease/increase the value Fixed - https://github.com/nvaccess/nvda/issues/9675#issuecomment-592997952 https://github.com/nvaccess/nvda/issues/9675#issuecomment-59... > is reported as unlabeled edit field when using nvda+tab Fixed - https://github.com/nvaccess/nvda/issues/9675#issuecomment-592997952 https://github.com/nvaccess/nvda/issues/9675#issuecomment-59... --- I want to point out that this article is out of date and basing any sort of modern FE development decisions on it merits much more research than just "GOV.UK tried it and it hurts accessibility" ... I attest that not using the correct input type on fields is more of an accessibility issue - especially numeric fields.

inetknght 4y ago

> I plan to create my own custom number input that has its own increment/decrement buttons. How will you handle users who have javascript disabled? Why reinvent the wheel? Why not fix whatever problem you have with numeric input?

padseeker 4y ago
The whole thing WILL NOT WORK without javascript. The rules engine runs in the browser, which is why you get that instant feedback loop. Admittedly keenforms isn't for EVERYONE. There are built from scratch forms that use React or Angular or Javascript that provides instant feedback. Its not impossible to forgo JS but its hard to create a better UX with the instant feedback that only javascript can provide.
- easrng 4y ago
  Plain HTML can do validation with regexes (pattern attribute) and the required attribute.
geraldwhen 4y ago
If you want masking, and you DON’T want spinners, text makes just as much sense. Think a currency input, or SSN, or zip code field. You almost never actually want the functionality of an html number input.
peterangular 4y ago
> How will you handle users who have javascript disabled? They won't/can't. Their only real options are to fallback to either the "text" field or the "numeric" field. > Why reinvent the wheel? Why not fix whatever problem you have with numeric input? JS devs will prioritize chasing after their ideal UIX long before they consider things like JS being disabled, screen readers, ARIA tags, cross-platform compatibility, etc. There's countless replacements for long-supported HTML input fields that still get active development: date pickers, numeric inputs, sliders, you name it. If it exists in the base W3C spec someone has likely reinvented the wheel for every purpose from pixel-perfect skeuomorphism, to aggressive input masking, to "instant feedback," to vaguely claiming "you cannot trust the number input" - the list goes on and on. --- OP if you're reading this - I hope you're considering JS being disabled (graceful + functional fallbacks), ARIA, aggressive cross-platform testing, and testing with real screen readers. If you aren't, this is not an accessible service.

operator-name 4y ago

The UK Government design team have a blog post on this: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des... > Avoid using inputs with a type of number > Do not use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong. (https://design-system.service.gov.uk/components/text-input/#numbers https://design-system.service.gov.uk/components/text-input/#...)