I'm trying to find a way to make screen readers like NVDA of Windows Narrator stop reading an input value and read the aria-describedby only instead.
Here's the case, I have a web component that is a mask-input field. Let's say it is configured with a phone mask set to (___) ___-____ where underscore can only be numbers. Right now the screen reader would read left parens, 3 lines, right parens, space... and so on and then read what I set as the aria-describedby value which would be something like "Phone number, 1231231234" which use the unmasked value of my component.
What I'd like, would be the screen reader to only say "Phone number, 1231231234" which is my aria-describedby value and skip the rest so it keeps short and avoid saying things that can confused impaired user..
A bit of background, maybe this can change a bit the response, my component is built with Aurelia, I'm leveraging the binding system to update the value.
Is this something possible? I there a few alternative? I'm I completely off-track with what I'm trying to achieve?
Thanks!
There isn't a lot you can do to maintain accessibility with this approach. It is very important for the screen reader to read out the contents of the input field, otherwise when a user types a number it will not tell them what that number is - also if they decide to go back a character or forward a character, the value will read the label and not something they've entered. I imagine the input mask you're using is using javascript to replace a masked character with the user submitted one on keypress?
It is generally best practice to outline what the required input format is in the label or in descriptive text associated with the label. This will allow sighted users to easily match the required format and also allow visually disabled users to use their keyboard to navigate the input value with full knowledge of what the desired format is. I've thrown together a quick example of this.
<label for="textInput">Phone Number</label>
<span id="phoneDesc">Please use the following format: (xxx)xxx-xxxx</span>
<input id="textInput" type="text" aria-describedby="phoneDesc" />
It could also be helpful to look into the general usability of input masks - a lot of people tend to find them troublesome.
https://www.nngroup.com/articles/stop-password-masking/
If you're determined to use them and don't mind a different approach from your 'line' based approach, maybe give politespace a try (I have not tried this, but it could be worth evaluating for your needs)
https://github.com/filamentgroup/politespace
Related
I'm trying to improve screen reader support on our webapp, but I'm struggling a bit with what the best practice is for our buttons. Our current pattern looks something like this
If I focus on the button, should the screen reader say...
...Choose file, required?
...Upload personal letter: choose file?
...Upload personal letter: choose file. Allowed filetypes: doc, docx. Required?
We're currently going for the more talky version, but our team has limited experience with screen reader users and how they're used, so a push in the right direction would be very helpful. Thank you. :)
There is no real rule. It should be fine as long as indications are clear enough for the user.
In fact, it depends a lot on how you are used to your screen reader, Internet and your device in general:
Advanced users tend to prefer shorter labels and may be annoyed by longer ones.
Beginners may not understand if the label is too concise
Beginners may also be overflowed if the label gives too much extra information, or don't understand if the vocabulary is too technical
Screen readers have many options allowing you to decide what to say and what not to say. For example, Jaws calls that verbosity and there are 3 general levels that are further customizable.
Sadly, on the web, you can't determine the selected level, nor adapt the markup knowing that this element is only spoken in advanced or intermediate mode (this can be further highly customized anyway)
So the best is probably the middle option: be not too concise, but not too verbose either.
I'm a screen reader user myself; as an advanced user, regarding your propositions; I would say:
The second gives more confidence on what you expect exactly than the first one. If there are several files to upload, for example a cover letter + a CV + a photo, it's very important to have the information, so that there is less risk to mess up, i.e. upload the photo in the CV field.
If there are several fields with the same label that are labelled the same, it's hard to know which is which.
Indicating the allowed file types and other requirements of that kind is very good, but it is probably better placed outside the label.
Remember that the entire label is spoken again each time you tab into the field. If there are 5 fields with the same information, or if the form is complicated and you must go back and forth several times, it's annoying to hear many times the same.
So, I would go for a variation on the second one: "upload personal letter, required".
And indicate somewhere else in the page technical constraints like file type, size, etc. because it's still a very good idea.
Note that the "required" information can be left out from the label if you put the required and aria-required attributes on the field. It's the recommanded way to indicate that a field is required.
Tl;DR: Keep it concise.
If you want to convey some additional info like allowed file types, sizes, "no viruses please" etc., do not put this on the button itself. Prefer, for example, aria-describedby and make a separate control describing all those things, visually connected to the button (say, to the right of it).
We, I mean screen reader users, often navigate by items and do other weird stuff like invoking list of all buttons on the page (even Narrator nowadays started supporting such things), so if the button label is too long, it would be irritating too shortly.
TLDR: Which input type can utilize the mobile numeric keyboards AND implement masking with spaces injected and a max limit for CVV and Credit Card inputs, such as: XXXX XXXX XXXX XXXX
When building forms, I have seen a varied degree of consistency surrounding the correct input type for credit cards. Here are my discovered pros and cons for each:
type=text
Able to mask easily with various libraries such as cleave.js or set maxLength attribute
Mobile users do not receive numeric-only keyboard, unless setting range to [0-9] (Only iOS users will get this experience, leaving Android users with full keyboard)
type=number
Proper keyboard shown on iOS and Android but unwanted characters can be entered and no maxLength can be set. Min and Max do not limit users from inputting more than 16 characters but do provide error messages when over the max. *Note, this input type is basically ruled out due to leading 0's being deleted. (Unacceptable for CVV's)
type=tel
Able to properly mask and is utilized all over the place, BUT may have unknown impacts on accessibility programs and autofillers. If anyone can provide clarification on the potential side effects of using this input type, that would be awesome!
These are all the types that came to mind. If anyone has any other recommendations, please let me know!
HTML
If you're trying to do this strictly with HTML, I believe the following is going to get you about as close as is currently possible:
<label for="ccn">Credit Card Number:</label>
<input id="ccn" type="tel" inputmode="numeric" pattern="[0-9\s]{13,19}" autocomplete="cc-number" maxlength="19" placeholder="xxxx xxxx xxxx xxxx">
inputmode sets the keyboard type (in this case, numeric)
pattern enables validation (in this case, numbers and spaces with a length of between 13 and 19) and it helps with keyboard type for browsers that don't yet support inputmode
autocomplete tells browser what should be autocompleted (in this case, a credit card number)
maxLength prevents the user from entering more than the set number of characters (in this case, 19, to include numbers and spaces)
placeholder gives the user an example (formatting hint)
JavaScript
For a more robust solution, JavaScript is going to be required. And rather than roll your own solution, it'd probably be best to use a battle-tested library. Cleave.js (as you mentioned) is a popular choice.
I’ve seen using type="tel" on many places, for the reasons you mention.
I would not recommend type="number" as then you have to fiddle with in/decrement arrows etc. And from certain point of view it is not a “number” in terms of what we usualy do with numbers (maths), see this comment on CSS tricks forum.
Another trick how to force numeric keyboard is using pattern="[0-9]*". This should work on iOS only. To make it work on Android as well, you have to combine it with the type="tel".
There's an attribute inputmode that's designed for that, it's not implemented yet (actually deprecated in HTML 5.2), but there's work done on it (FF/Chrome).
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
And see this discussion:
https://github.com/whatwg/html/issues/3290
For now set the autocomplete attribute to the correct value:
https://developers.google.com/web/updates/2015/06/checkout-faster-with-autofill
or implement a customized input with mask like you're using now.
Is it best to use a 'text' attribute with a limit on the number of characters, or can I use a number attribute in an input for a zipcode.
Just trying to get my head around all the different attributes with the forms in html5.
Cheers
You can try this
<Label>ZIP Code</Label><input type="text" pattern="[0-9]{5}" title="Five digit zip code" />
“Should” is a strong word, but there is actually a “should” class statement about issues like this. HTML5 CR says about input type=number:
Note: The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a
number. For example, it would be inappropriate for credit card numbers
or US postal codes. A simple way of determining whether to use
type=number is to consider whether it would make sense for the input
control to have a spinbox interface (e.g. with "up" and "down"
arrows).
The means that the only feasible element for the purpose is input type=text, when using built-in constructs. You can use the maxlength attribute to set the maximum number of characters (works on all browsers) and additionally a pattern attribute what specifies the allowed characters and combinations, too; its value naturally depends on the zipcode type(s) to be used. For international postal addresses, you probably should not use any pattern or even maxlength, since the formats vary.
To allow ZIP+4:
<input type="text" placeholder="Zip Code" title="Please enter a Zip Code" pattern="^\s*?\d{5}(?:[-\s]\d{4})?\s*?$">
To be friendly to the user, this also permits whitespace before/after the string, which the developer will need to trim serverside.
If you have any international users you are going to want to allow alpha numeric via type="text"
Example: UK postal codes are formatted as AA9A 9AA
9 = any number
A = any letter
There are various options from my POV, but I think the best is already given by Md Johorul Islam: the pattern attribute.
The options:
Use a regular expression (the pattern attribute);
Use a custom (jQuery) mask control, like jQuery mask;
For the platforms where this is not supported, use type=text with a maxlength.
Note: Despite these options: always validate server side!
"Best" is subjective/contextual. But from a usability perspective, Zach Leatherman studied number-ish inputs in 2016 and specifically addressed the ZIP input.
The goal was to make "big number keyboards" appear on mobile devices. This may seem insignificant, but easing form input in e-commerce checkout forms is an important goal.
It seems that some day the inputmode="numeric" attribute will be appropriate for zip inputs. But for now, only Chrome/Android supports it (Firefox has it behind a flag).
Zach developed a small library called numeric-input as part of his formcore package which will implement the best possible case for whatever browser is being used.
Keep in mind, the library is a couple years old, and browser behavior might have changed since then.
You can use either and the form will work. However, it might be a better idea to use number because, for example, mobile devices would invoke a different keyboard layout - with numbers and helper characters instead of the full alphanum keyboard.
But, if you think setting one type as opposed to another will offer a higher level of security, you're wrong. No matter which type you put, it will offer you no security. Every form input needs to be checked on the server as well - that's where the real security check happens. The check that you do in browser, is more of a UI/UX thing.
Here is a nice article about different input types: http://html5doctor.com/html5-forms-input-types/
<input type="tel" pattern="[0-9]*" placeholder="Zip Code" max="99999" />
Type set tel to show numeric keypad, pattern to except values 0-9 and max set to prevent values beyond US 7 digit zip codes.
There are several hidden form fields on my pages that are used for passing data to server side. For debugging purposes, I feel it easier to hide all eligible input fields by just making them all a part of hidden class than setting the type=hidden attribute on each input field.
Whenever I need to debug I could easily modify that class attribute to enter debug mode. Ofcourse both the approaches work in hiding the input fields but I am not sure as to why this approach(hiding via class) isn't much widely used in real life. Can you throw some light on what should be preferred approach ?
<input type="hidden"> won't trigger input validation, auto completion, and other user interaction related events. It's designed to save raw data, without user's direct input.
But a <input type="text">, visually hidden, are still going to be considered as a user interaction component. And on some devices enabled visual aid, it will serve as not hidden, and cannot provide the consistency you expected. That's why it's not preferred to do so.
Eg. a <input type="hidden"> won't auto complete it self, or preserve the inputted data before refreshing a page, or prevent the form from being submitted for a failed type validation can't even be seen.
The CSS approach is bad for usability, and accessibility. Think of someone with CSS disabled (very old mobile phones, people with a screen reader), they won't render your CSS as you might expect, and the input with all of its glory would be displayed to the user.
A hidden input should be used for implied user input, meaning, input that would come from the user, but is implied and does not need to be manually entered.
Your question falls more onto the type="hidden" approach.
I'd recommend using <input type="hidden" /> because it is the standard way of HTML to hold a user's input value. If you use another attribute for type and hide it with css, one problem may arise is that when the css fails to load, the input control will show up.
I think your question is about the best approach for debugging form fields. I recommend keeping them as type='hidden' in your HTML. This is best for you, for your users and for semantic interpretation of the page.
Instead, use a tool like the Chrome Developer Tools to do your debugging. This will let you easily see the values of your hidden fields.
Excuse me for the maybe very stupid question, but my curiosity is killing me, and plus I'm new to this, but are using labels important in your markup, and why?
i.e.
<label for="birthdate">Birthdate:</label>
<input type="text" id="birthdate" name="birthdate" />
Why must I label this input, why is it beneficial to the user, why is going to be beneficial for future use, or is it search engine optimization thing. That's what I really wanna know :)
It's important for a number of reasons:
Clicking the label focuses on the
text field, which is something a lot
of users expect.
It's helpful for the accessibility reasons.
How else is the user going to know which field is which? You could use
just text or a span or something, but
why would you?
It leads to a more semantic markup.
It helps for accessibility, e.g. screen-readers.
Also for things like checkboxes it allows the user to click on the label and not just the checkbox itself (Try it!).
It's important for accessibility, so blind people using screen readers can easily tell which text box is meant for which thing, since possibly otherwise their software cannot tell the purpose of the active text box from the page structure. Also, clicking on the label will focus the appropriate input control, which is convenient.
Future use:
In a case where the input html form is directly linked with database ( happens in frameworks)
so the input form variables directly represent database columns.
So, instead of showing database column names to the user in the form, we can show simplified names to the user using Labels.