My recommendation for the last couple of years has been to layout forms
Issues like the one you are describing is a good reason for following this layout, but so is the small screen use case where they visitor may not have scrolled down far enough to see the error message or note.
It depends on how you approach this component. Every component's identity, operation, and state should be available to assistive technology to make it accessible.
When an arrow is on keyboard focus, screen reader should inform the user about the identity of the element (Up arrow) its state (clicked/ unclicked) and operation (press enter to increase the ...
It could be because, back in 2001 when Rob Chandanais of BlueRobot came up with the pure CSS version of this layout, our monitors were much smaller and resolution wasn't as high. Websites had an infinite amount of vertical space, unless you wanted horizontal scrolling. Therefore you could have a lot more navigational items in the menu. Also, it was arguably ...
I agree with you that your suggested tab order is better than the default.
Best way forward is to test what way the matrix makes more sense to people. I for one and the person next to me where a bit confused by the current layout and would prefer to swap the axis, which would also solve your tab problem. Additionaly I would remove half the lines so you ...
(expanding comment into answer:)
For mobile users you can use the nonstandard role="text" on the parent element. It's hacky and only works on WebKit, but that is fine since in my recollection, only VoiceOver will (incorrectly) break a line in parts when it encounters an inline element. NVDA, JAWS and (I believe) TalkBack will read the line at once correctly, ...
It sounds like you're familiar with WCAG (Web Content Accessibility Guidelines), but just in case others are not, there are two guidelines for links (not buttons).
2.4.4 Link Purpose (In Context) [Level A]
2.4.9 Link Purpose (Link Only) [Level AAA]
Minimally (Level A), the purpose of a link can be determined by the link text and its context. So if you ...
If this is for a web-only site, what about using two different underline styles on hover?
single (normal) underline for links that open in the same window
double-underlines for links that open in a new window
Or using one of the nifty hover states from http://ianlunn.github.io/Hover/. The speech bubbles are interesting
You cross-posted this question on stackoverflow.com too. I answered it there with pretty extensive details but am including the answer here too to make it easier for others to find the answer.
The answer depends on the level of conformance you're trying to achieve. Most companies (and most country laws) require AA conformance. In fact, the guidelines say ...
So, to precise your demand, it would be something like wikipedia thing at the end of articles? ( Example : https://en.wikipedia.org/wiki/Supply-side_platform )
If yes, I think that showing it won't disturb that much. Or maybe implement something like Reference anchors to show a "list" of those links at the end of your articles ?
If you want to open new ...
I know it's 4 years late, but my solution is to have a third radio option for "mixed values". This option only appears when applicable. If the user selects option A or B, the mixed values option then disappears or disables. This way you still have one and only one option selected at all times but still communicate to the user that this input was mixed.
One way of helping the user would be adding the max-chars number in the aria-label.
Additionally, if you wanted to insert a 'You've reached the max number of chars' message you could use aria-live=polite to let the screen reader know that this field may be updated - in this case with an extra validation error.