Previously Paul J. Adam explained how to build ARIA role=”alert” Modal Dialogs in his A11y support series. In his latest post in the series, Paul details how to build another ARIA widget: a simple role=”button” UI control. He also explains what screen reader and browser combinations are supported when using other ARIA attributes allowed on role=”button.”
Do headings introduced to meet SC 2.4.10 (AAA) need to be marked up With an h<n> tag too? On this […]
This illustrates why accessibility support in terms of differences in navigation techniques and HTML / ARIA behavior on a mobile device needs to be taken into account during design.
Sometimes, the visible anchor text as mandated by the user interface design is not very meaningful to vision impaired users. One could use aria-label or the title attribute or even off-screen text on text links. But what’s the best practice based on current assistive technology support?
Aria-invalid=true Setting aria-invalid to “true” is a quick and easy method for indicating that a field has failed validation. Yet, […]
Because the attribute “aria-required” is supported by commonly used browser-assistive technology combinations, many consider its use as the easiest and […]
“Techniques for Labeling Standard HTML Form Controls” is an advanced accessibility technique post by Deque Principal Consultant Sailesh Panchang. In this […]
ARIA vs Old School HTML Which side of the fence do you stand on? Are you ready to defend your […]
Some accessibility experts are of the opinion that they have a general agreement about using WAI-ARIA wherever and whenever one […]