tabindex="0" and tabindex="-1" have special meaning and provide distinct functionality in HTML. A value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as <div>, <span>, and <p>) to receive keyboard focus. Of course one should generally use links and form controls for all interactive elements, but this does allow other elements to be focusable and trigger interaction.
Group items tagged
WebAIM: Blog - JAWS ate my tables - 0 views
WebAIM: Keyboard Accessibility - Tabindex - 0 views
-
-
A value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as <div>, <span>, and <p>) to receive keyboard focus.
-
A tabindex="-1" value removes the element from the default navigation flow (i.e., a user cannot tab to it), but it allows it to receive programmatic focus, meaning focus can be set to it from a link or with scripting. This can be very useful for elements that should not be tabbed to, but that may need to have focus set to them. A good example is a modal dialog window - when opened, focus should be set to the dialog so a screen reader will begin reading and the keyboard will begin navigating within the dialog. Because the dialog (probably just a <div> element) is not focusable by default, assigning it tabindex="-1" allows focus to be set to it with scripting when it is presented.
- ...1 more annotation...
Using ARIA - 0 views
-
aria-describedby with single or multiple id references
-
aria-label and aria-labelledby have similar behaviour in screen readers and the Accessibility API, but aria-label should be reserved for when there is no visible text on the page to reference or when keeping track of id values would be too difficult.
HTML5 Accessibility: aria-hidden and role="presentation" | Unrepentant - 0 views
-
any user accessing the Accessibility API
-
aria-hidden=”true” + role=”presentation”
-
Use both attributes for cases where browser/OS/screen-reader combinations don't support WAI-ARIA.
-
Inclusively Hidden | scottohara.me - 0 views
-
sometimes content is for decorative purposes only, and it would be optimal to not announce this content to assistive technology.
-
don’t use aria-hidden on focusable content
-
Purposefully Hidden from Assistive Technology
- ...1 more annotation...
-
There are various techniques to visually hide content in our web interfaces, but are you aware of the different effects they have on the accessibility of that content? While it would be nice if there was a single, native, solution for hiding content, there are contextual benefits to the various techniques at our disposal. Since there have been many articles already written about these techniques, over the many years they've been in use, the focus of this article will be to highlight the ones that are most appropriate for modern web development. We won't just look at the code behind each of these techniques, instead we'll focus on why each technique has its place, using practical examples to demonstrate their purposes. But before we talk about how to hide content we should ask ourselves a question… Why are we hiding content?
Prettier Accessible Forms · An A List Apart Article - 0 views
-
The fieldset element allows us to group form controls into logical, related “chunks.” legend then allows us to add a caption to that fieldset, which helps users understand the context of the form controls contained within that fieldset. In some screen readers, the legend is associated with each form control within a fieldset and is read out after each tab of the keyboard, so that a particular control can always be referenced back to its legend.
-
-
"The most important part of a form is the HTML we use to build it. Fortunately, HTML gives us a nice assortment of tags to build our forms in an accessible way. These are fieldset, legend, and label."
WCAG 2.1 is Coming-and Here's What You Should Know Right Now - Siteimprove - 0 views
-
Expect the new WCAG standards to emphasize a mobile experience that matches what users might expect from a traditional browsing session. This will likely include making your site’s touch screen functions more compatible with assistive technology.
-
The new standards are expected to raise that level to 400% to help users with low vision navigate sites more smoothly.
-
WCAG 2.1 will likely seek to place limits on where and when pop-ups and similar advertising can appear.
- ...1 more annotation...
-
Considering how massively the online landscape has changed in the past decade, it's amazing that international standards for web accessibility haven't been updated since December of 2008. That's about to change. After soliciting and assessing recommendations from the public, the international Web Accessibility Initiative is set to announce version 2.1 of its Web Content Accessibility Guidelines in the middle of this year. As that update draws nearer, there are a few key changes website owners may want to start planning for. (Keep in mind that all WCAG 2.1 changes are tentative.)
WebAIM: To ARIA! The Cause of, and Solution to, All Our Accessibility Problems - 0 views
-
this role is often used extraneously (<button role="button">)
-
aria-label can also override other important information such as link text
-
aria-expanded This can tell screen reader users that activating a button or link will cause content to expand and collapse below (e.g., an accordion), and also whether it is currently collapsed or expanded.
« First
‹ Previous
61 - 69 of 69
Showing 20▼ items per page