Number fields should not always be right-aligned
It often makes sense to right-align numbers when they are being compared to other number fields (e.g. in financial statements). This can help comparability and scannability.
However, sometimes number fields are unrelated or are mixed with text fields in a form, so left-alignment may promote better visual ...
I do work on a professional webapp for visually impaired, screen reader users.
We do user testing regularly, and this has been raised many times during user test sessions that disabled elements that are required for completing a step/ flow (or are just generally too important to be missed) should be focusable with TAB key.
If disabled buttons are not ...
I've taken the time to draw some wireframed examples that might help you decide on how to design your time-picker control. Below you can see 3 screenshots which show (IMAGE 1) a time-picker control for all units, an increment button, decrement button, numeric input field and unit picker dropdown (if needed.)
IMAGE 2: The idea is that you set it up so that ...
Another option is a logarithmic slider, like this:
download bmml source – Wireframes created with Balsamiq Mockups
This is appropriate when the value can span multiple orders of magnitude, but the number of significant figures is low. It will not allow the user to select between, say, 500 ms and 501 ms, so I suspect it might not be what you need. It ...
This is a bit of a tricky one.
Normally, with regular form elements, it would be best to fully remove anything you can't interact with or serves no purpose.
However, that particular button you're talking about (the "next step" button) can also act as a guide to the level of completion - i.e. you are not able to proceed to the next step until the form ...
The consensus is that it is not ok to use placeholders to replace labels.
I see two issues off the top of my head with right aligning text in an input type ="number"
When the number selector is not visible it looks quite strange with the number awkwardly floating a bit off from the right.
When there is a number already filled in, and you want to add more digits to it, you have to click in the small margin between the last number ...
I recommend going with a list approach since as per your current code you are just providing the content in a linear order which can be read by a screen reader without issues. However if you did use Lists for indenting then, accessibility would become an issue as highlighted from the W3C guidelines
The HTML list elements DL, UL, and OL should only be ...
I think this article gives a nice overview of WAI-ARIA vs. HTML5 and how to use them in practice.
From the above examples what can we conclude. Firstly, the primary, if
not sole, purpose of WAI-ARIA is to provide information about elements
in an document to assistive ...
As a marginal counterpoint to @Leths, a screenreader lets you get to every object on the page, whether disabled or not, unless they're specifically hidden from the screen reader using aria-hidden=true. I didn't want to add this as a comment to @Leths' posting because this is an important point related to the main question. That is, even if you decide not ...
Ceefin's answer makes a very good point. By focusing too much on the details you can overlook what actually matters about UX, which is what the user experiences. And there's no more frustrating experience than a form that asks a simple question, then doesn't let you answer it. This kind of over-validation is horribly common with postal addresses-- I've ...
As with a lot of UX questions, the answer is 'it depends'. Numbers are right aligned because it makes them easier to compare. In an input field however, you may be entering numbers where it makes sense to compare, or you may not. Because you can't say with confidence, it makes more sense to left-align numbers by default than to right align.
"Parallax" is a term for the optical effect we see when we change our position in relation to things at different distances:
Due to foreshortening, nearby objects have a larger parallax than more distant objects when observed from different positions, so parallax can be used to determine distances.
Technically, the effect on that site isn't parallax, but ...
Ultimately, the optimum width and breakpoints for a website depends on the content that it displays.
That said, the great part about responsive design is that you can cater towards not only smaller screens, but larger displays as well. You can use a 960 breakpoint, but you can also use 1200, 1400, etc.
Take a look at this UX/Design guideline from Google about Confirming and Acknowledging:
Although the guideline is for mobile applications, the principle and flowchart highlighted in the guideline can help you and your team decide when and when not to use alerts and confirm dialog.
Using many input controls with different measurments is rather not optimal, because user will spend time to decide, which one fits to him.
You may trim and move x100ns outside edit:
download bmml source – Wireframes created with Balsamiq Mockups
If odd value is entered, after leaving focus it is corrected to odd (lesser or bigger).
Also in similar ...
If its acting as a value then why not have it as a value?
The placeholder text should be used to hint at the type of entry that is required. In your particular scenario I would either set the value attribute to Any instead of the placeholder attribute. Then if the user wants to change the value they can, else they leave it as Any and tap Select.
Edit: The logic is that only if an element responds to events it can be focused. However as @Leths comments from his experience this can be detrimental in some cases. So I guess the best thing to do is follow what your users would expect and what it would be most beneficial for them.
No, if the user can't interact with the element don't give the (focus) ...
Developing for mobile devices in HTML5 is no different than developing in HTML 4.01 or XHTML, since User Experience is platform agnostic. Buttons need to look like and act as Buttons whatever platform you're using. I know that you can do much more on HTML5, but that doesn't change the User Experience of mobile devices. You just have to implement standard UX ...
I have nothing but intuition to back this up, but the following heuristic might work:
Is there one absolutely unambiguous point of attention on your page? An area for which you can say with absolute certainty that your user will look at as soon as the page loads? Is the main element in that area a form with either one input element or a very clear ...
There is already a an interface in hardware design where a potentiometer or rheostat has a switch at one of the ends of the range. In some cases, it is used as an on/off switch, e.g. for a cheap amplifier where there is a singular control (volume).
I would suggest having a similar control where sliding all the way to one side provides feedback that the ...
I will suggest you go with radio buttons over slider, because sliders lack the very important features such as: Precision, Speed, Cognitive Load etc.
Here's a fantastic study done on this topic (the article is a little long but trust me, you will enjoy the read and findings):
Exploring Slider vs. Categorical Response Formats in Web-Based Surveys
The time element is a machine-readable element. So it is mainly used to help out the computer not the user directly.
The element in HTML represents a machine-readable date, time, or duration. It can be useful for creating event scheduling, archiving, and other time-based functions.
The uses of unambiguous ...
The problem will be that the typical non-chrome user is the one who desperately needs a datepicker (I'm pretty sure the devs can live without it, I mean, I'm partly a dev, and I know how to use command line if needed), and that will be the clerical.
Therefore, you either tell them to change the 'browser' to 'chrome' (they won't understand that), or you just ...
I think the latest guidance is to not bother with them. They often compete with other navigation aids, JAWS for example. I believe people like the BBC in the UK have dropped access keys, and I recently helped build a central government UK site without these access keys.
If you are talking about input field types then for old IE just use type="text".
Date field. In Chrome it allows you to select a date using inbuilt calendar. Alternative for inbuilt calendar is jQuery datepicker
Email field in Chrome has inbuilt validation, use jQuery for email validation.
They're not necessarily mutually exclusive. You are correct that HTML5 has provided a few more semantic containers, but that is just a small part of the scop that ARIA covers, so you still want to be in the habit of using ARIA.
In theory, you are correct, that eventually the nav container should be recognized by screen readers and you wouldn't necessarily ...
Assuming your question isn't about how validation should be implemented but about how validation should work to keep user experience smooth and uniform across all devices. If it's about implementation then Stack Overflow (for example) is a better place (but you should edit your question according SO's rules).
Let's take, for example, a simple ...
My bank has a strict 5-digit pincode policy and the input looks like as many underscores as there are characters allowed. It's very minimalist, yet you quickly get that each corresponds to a character. Here's an approximate rendering of it:
A B C
_ _ _ _ _