5 ms·

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

> > 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.
- peterangular 4y ago
  > But you appear to have confused the article section titled "Accessibility" with the concept of accessibility. I mean. Yeah - I guess I expect the section named "Accessibility" to be about the concept of accessibility. --- > 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 So, just like a telephone number - CC #'s are not technically numeric as they're more accurately thought of as a "sequence of numbers"... and funnily enough many people will sorta hijack the functionality of the <input type="tel"> using "pattern" and other attributes to input them correctly. Whatever the case is, it is considered a bad practice to use type="number" for a CC field. type="number" specifically is for when a field is a numeric "value" - this is not the case with a CC number as it's a sequence of digits (as-in the value of the digits doesn't mean anything). Your point is valid for very large numbers, or numbers with incredible precision. Sometimes yes, those extreme values can cause weird non-intuitive behavior from the number field. While I have ran into these use cases, I 100% consider them to be edge. Most people aren't inputting numbers that large into an application; and it can actually be considered a bad UIX practice (ex: making someone enter a large value in bytes vs. smaller value scaled in gigabytes). --- > 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 So, Safari is on 15 and according to https://caniuse.com/usage-table https://caniuse.com/usage-table it is 0.02% the market share. Every time we create software targeting the browser as a presentation layer we have to ask ourselves what the acceptable market cut-off for browser support is. This is largely dictated by the nature of the software, who is using it, geographies... lots of things. Unless the solution warranted, or the client demanded incredible backwards compatibility, I would not shackle myself to supporting browsers with that low of a current use %. The economics for my time, vs. what I would sacrifice in capability just do not work out. Also, I don't have the scale of Facebook or Google where I need to support... everything. 99.9% of the time I just need to support reasonably modern browsers 3-4 major versions back. --- > 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. Although browsers differ in how they handle value changing on scrolling for number fields (Chrome: no change, FF: value changes), I don't think it's outside of the realm of expected functionality... Similarly, if you click on a dropdown element gives it focus, scrolling the mouse wheel the dropdown will select different options; even if the cursor isn't directly over it. The same is true with other inputs, my cursor is not on this <textarea> but I am still able to type within it because it has focus. It will not lose focus unless I click off of it. I sorta get how this behavior doesn't translate well for the number field. I will note you can easily stop the behavior with onscroll="return false" attribute or a JS event listener with event.preventDefault() ... I've seen both in the wild and they're fine solutions. Even for no-JS users I think it's still OK since they've consciously opted-in to the default browser behavior for stuff like this. But still - it's not completely outside of the realm of unexpected behavior for an input to still react to scroll if it the element has focus. And, if it's a problem it's incredibly easy to fix and still get all of the accessibility benefits that a number field offers. --- > You need to do some real testing I find this aggressive. Although you have clearly decided I haven't... I have. I just think people making real arguments against the using numeric input elements is off. I've used them for years now without encountering the edge cases people are throwing out there; and, I still find using the 2020 GOV.UK site as basis against the use is problematic. I think often it's more accessible to use them when appropriate, even given the quirks we've discussed. I've shared my thoughts - feel free to rebut for others to read, but I'm fully done conversing on this with you.

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.

peterangular 4y ago
> But you appear to have confused the article section titled "Accessibility" with the concept of accessibility. I mean. Yeah - I guess I expect the section named "Accessibility" to be about the concept of accessibility. --- > 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 So, just like a telephone number - CC #'s are not technically numeric as they're more accurately thought of as a "sequence of numbers"... and funnily enough many people will sorta hijack the functionality of the <input type="tel"> using "pattern" and other attributes to input them correctly. Whatever the case is, it is considered a bad practice to use type="number" for a CC field. type="number" specifically is for when a field is a numeric "value" - this is not the case with a CC number as it's a sequence of digits (as-in the value of the digits doesn't mean anything). Your point is valid for very large numbers, or numbers with incredible precision. Sometimes yes, those extreme values can cause weird non-intuitive behavior from the number field. While I have ran into these use cases, I 100% consider them to be edge. Most people aren't inputting numbers that large into an application; and it can actually be considered a bad UIX practice (ex: making someone enter a large value in bytes vs. smaller value scaled in gigabytes). --- > 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 So, Safari is on 15 and according to https://caniuse.com/usage-table https://caniuse.com/usage-table it is 0.02% the market share. Every time we create software targeting the browser as a presentation layer we have to ask ourselves what the acceptable market cut-off for browser support is. This is largely dictated by the nature of the software, who is using it, geographies... lots of things. Unless the solution warranted, or the client demanded incredible backwards compatibility, I would not shackle myself to supporting browsers with that low of a current use %. The economics for my time, vs. what I would sacrifice in capability just do not work out. Also, I don't have the scale of Facebook or Google where I need to support... everything. 99.9% of the time I just need to support reasonably modern browsers 3-4 major versions back. --- > 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. Although browsers differ in how they handle value changing on scrolling for number fields (Chrome: no change, FF: value changes), I don't think it's outside of the realm of expected functionality... Similarly, if you click on a dropdown element gives it focus, scrolling the mouse wheel the dropdown will select different options; even if the cursor isn't directly over it. The same is true with other inputs, my cursor is not on this <textarea> but I am still able to type within it because it has focus. It will not lose focus unless I click off of it. I sorta get how this behavior doesn't translate well for the number field. I will note you can easily stop the behavior with onscroll="return false" attribute or a JS event listener with event.preventDefault() ... I've seen both in the wild and they're fine solutions. Even for no-JS users I think it's still OK since they've consciously opted-in to the default browser behavior for stuff like this. But still - it's not completely outside of the realm of unexpected behavior for an input to still react to scroll if it the element has focus. And, if it's a problem it's incredibly easy to fix and still get all of the accessibility benefits that a number field offers. --- > You need to do some real testing I find this aggressive. Although you have clearly decided I haven't... I have. I just think people making real arguments against the using numeric input elements is off. I've used them for years now without encountering the edge cases people are throwing out there; and, I still find using the 2020 GOV.UK site as basis against the use is problematic. I think often it's more accessible to use them when appropriate, even given the quirks we've discussed. I've shared my thoughts - feel free to rebut for others to read, but I'm fully done conversing on this with you.