Skip to main content

Home/ Web Accessibility/ Group items tagged labels

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Sandra Earl

Multiple form labels and screen readers | 456 Berea Street - 0 views

www.456bereastreet.com/...form_labels_and_screen_readers

accessibility forms labels JavaScript alerts

shared by Sandra Earl on 12 Oct 10 - Cached
  • Well, it turns out you can do that. From The LABEL element in the HTML 4.01 specification: The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control. The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute. Sounds great, doesn’t it? A quick check in graphical web browsers shows that they associate multiple labels with the input field (as evidenced by the input field gaining focus when either label is clicked). But what about screen readers? It would be so useful if this would work… Unfortunately, and perhaps unsurprisingly, it looks like it doesn’t quite work as well as you’d hope. I mentioned this briefly in Use the label element to make your HTML forms accessible, but I think it’s worth bringing up again since full support for multiple labels would help us make forms more accessible to screen reader users while keeping visual designers happy. I am far from an expert user when it comes to screen readers, but I’ve done some limited testing with mostly disappointing results. Apple VoiceOver does not recognise more than one label element associated with a form control and reads only the label that comes first in the document’s source order. JAWS and Window-Eyes both do the opposite and read only the last label when an input field gains focus. The only screen reader of those that I tested that does handle multiple labels is Fire Vox. The exact results may obviously depend on user configuration and reading modes, and there may be other screen readers that get it right, but these results indicate that screen reader behaviour is too inconsistent for multiple labels to be a reliable technique.
Vernon Fowler

WebAIM: Creating Accessible Forms - Screen Reader Form Accessibility - 0 views

webaim.org/...screen_reader

webdesign forms screen reader form reading usability accessibility

shared by Vernon Fowler on 07 Oct 12 - No Cached
  • This can be solved by associating form labels to form items on the page. The label should almost always be located adjacent to the form item itself. When a screen reader accesses a form item that has a <label> element associated with it, it will read the text within the <label> element and indicate the type of form item it is (e.g., "First Name. Text box" or "Age. Check box"). Labels are needed for all form elements, except for buttons; the screen reader reads the text that is on the button (e.g., "Submit button").
  • Let's hear what the form sounds like to a screen reader:
  • Let's hear what the form sounds like now, with the improvements that we made:
Vernon Fowler

Don't Use The Placeholder Attribute - Smashing Magazine - 0 views

www.smashingmagazine.com/...placeholder-attribute

inclusive input formdesign aria forms inclusivedesign hint accessibility form html

shared by Vernon Fowler on 27 Jun 18 - No Cached
  • To recap, the placeholder attribute: Can’t be automatically translated; Is oftentimes used in place of a label, locking out assistive technology; Can hide important information when content is entered; Can be too light-colored to be legible; Has limited styling options; May look like pre-filled information and be skipped over.
  • Move the placeholder content above the input, but below the label:
  • Development Here’s how to translate our designed example to code:
  • ...4 more annotations...
  • aria-describedby ensures that the p content will be described last, after the label’s content and the kind of input it is associated with.
  • By using aria-describedby to programmatically associate the input with the p element, we are creating a priority of information for screen readers that has parity with what a person browsing without a screen reader would experience.
  • The floating label effect, a close cousin to this phenomenon, oftentimes utilizes the placeholder attribute in place of a label, as well.
  • Content hidden by an on-screen keyboard. 3rd party keyboards with larger heights may have a greater risk of blocking important content.
  • Vernon Fowler on 27 Jun 18
     
    Not only argues for not using the placeholder attribute but also describes an inclusive input hint and how to code it.
Vernon Fowler

WebAIM: Creating Accessible Forms - General Form Accessibility - 0 views

webaim.org/forms

forms accessibility form labels fields general

shared by Vernon Fowler on 03 Feb 14 - No Cached
  • Screen reader users generally navigate through a form using the Tab key to jump from form control to form control. Associated form labels are read for each form control when the user navigates to them. Any non-label text content between the form controls is usually skipped over. Be sure to include important cues or instructions in associated labels or at the beginning of the form.
Vernon Fowler

Accessible forms using WCAG 2.0 | Web Usability - 0 views

usability.com.au/...ccessible-forms-using-wcag-2-0

forms accessibility html

shared by Vernon Fowler on 10 Feb 14 - No Cached
  • The label element is not used for the following because labels for these elements are provided via the value attribute
  • This technique inserts new content into the DOM immediately following the element that was activated to trigger the script. The triggering element must be a link or a button, and the script must be called from its onclick event. These elements are natively focusable, and their onclick event is device independent. Focus remains on the activated element and the new content, inserted after it, becomes the next thing in both the tab order and screen-reader reading order. Note that this technique works for synchronous updates. For asynchronous updates (sometimes called AJAX), an additional technique is needed to inform the assistive technology that the asynchronous content has been inserted.
Vernon Fowler

Using ARIA - 0 views

w3c.github.io/using-aria

accessibility aria

shared by Vernon Fowler on 31 Oct 18 - No Cached
  • 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.
Vernon Fowler

How do you figure? | scottohara.me - 0 views

www.scottohara.me/...how-do-you-figure.html

HTML5 markup accessibility screenreaders

shared by Vernon Fowler on 30 Jan 19 - No Cached
  • Vernon Fowler on 30 Jan 19
     
    A figure can be used with or without a figcaption. However, without a caption, or an alternate means of providing an accessible name (e.g. aria-label) a figure may not provide much value in conveying its semantics alone. In some cases, it may not convey any semantics at all if its given no accessible name.
Vernon Fowler

Prettier Accessible Forms · An A List Apart Article - 0 views

alistapart.com/...prettyaccessibleforms

accessibility formdesign forms screenreaders

shared by Vernon Fowler on 09 Feb 19 - No Cached
  • 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.
  • Vernon Fowler on 09 Feb 19
     
    "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."
Vernon Fowler

Bruce Lawson's personal site  : The practical value of semantic HTML - 0 views

www.brucelawson.co.uk/...actical-value-of-semantic-html

accessibility html mobile navigation

shared by Vernon Fowler on 25 Feb 19 - No Cached
  • styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we’re able to ensure that the author, publication date, title, and subheading are prominently featured.
  • If you plan to put things into microdata, please note that Apple, being Apple, go their own way, and don’t use a schema.org vocabulary here. Le sigh. See my article Content needs a publication date! for more. Or view source on this page to see how I’m using microdata on this article.
  • Apple WatchOS also optimises display of items wrapped in <figure> elements
  • ...4 more annotations...
  • First, choose the appropriate type attribute and element tag for your form controls. WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.
  • unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.
  • By choosing the right semantics now, a machine that I don’t know about yet can understand my content and display it in the best way for its users.
  • Semantic HTML will give usability benefits to many users, help to future-proof your work, potentially boost your search engine results, and help people with disabilities use your site.
Vernon Fowler

Places It's Tempting To Use Display: None; But Don't | CSS-Tricks - 0 views

css-tricks.com/g-to-use-display-none-but-dont

webdesign accessibility usability screen reader reading

shared by Vernon Fowler on 07 Oct 12 - No Cached
  • I recently heard a heartbreaking story about a blind girl trying to apply for college and the form had missing labels so she had no idea what to put in what fields.
  • @media queries Turning on Voice Over in OS X and using Safari is a screen reader. Now imagine that Safari window was open to a very narrow width and the page had some @media queries for handling smaller viewports. And say that @media query hides some things with display: none in order to better visually accomodate the space. This could be good or bad for accessibility. Are you hiding a bunch of crap that isn't important to the page? Or are you hiding useful things that a person using a screen reader should have access to like they normally would.
Vernon Fowler

Customise radio buttons without compromising accessibility - 0 views

www.chenhuijing.com/...out-compromising-accessibility

accessibility webdesign input buttons inclusivedesign

shared by Vernon Fowler on 16 Sep 18 - No Cached
  • go with option 3, a good ole’ opacity: 0 coupled with a position: absolute. Hidden but still focusable, well-supported across browsers. Just what we’re looking for.
  • opacity: 0
  • the label has to come after the input element in the source order
  • ...1 more annotation...
  • sad state of affairs when it comes to browser support for clip-path.
  • Vernon Fowler on 16 Sep 18
     
    "Customised radio buttons and checkboxes are a common design pattern found on the web, and it doesn't take too much to ensure that your beautifully designed toggles are still navigable via keyboard."
Vernon Fowler

WebAIM: To ARIA! The Cause of, and Solution to, All Our Accessibility Problems - 0 views

webaim.org/...aria-cause-solution

accessibility aria

shared by Vernon Fowler on 16 Oct 17 - No Cached
  • 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.
Vernon Fowler

Accessible Breadcrumb Navigation - 0 views

scottaohara.github.io/a11y_breadcrumbs

navigation accessible accessibility markup

shared by Vernon Fowler on 17 Jul 19 - No Cached
  • Being that a breadcrumb is contained within a nav element, it will be surfaced as a landmark to screen readers. Providing it an accessible name of "breadcrumb" (or whatever term may be more meaningful to your site) will help differentiate it from any other navigation landmarks in the current document, such as the primary navigation
  • using aria-label to provide an accessible name, and aria-current to indicate the currently active link
  • screen reader support for aria-current is rather good
  • ...2 more annotations...
  • Some other breadcrumb patterns remove the <a> element, or at least the href from the link. These examples retain the a href for current link, as without it, people using a screen reader and navigating by links, or via focusable content with the tab key would not come across the currently active link.
  • Breadcrumbs are useful on large websites where pages have clearly defined hierarchy.
1 - 14 of 14
Showing 20▼ items per page