Skip to main content

Home/ Web Accessibility/ Group items tagged HTML

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
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

HTML5 Accessibility: aria-hidden and role="presentation" | Unrepentant - 0 views

john.foliot.ca/aria-hidden

shared by Vernon Fowler on 23 Jul 18 - No Cached
  • any user accessing the Accessibility API
  • aria-hidden=”true” + role=”presentation”
    • Vernon Fowler
      Vernon Fowler on 23 Jul 18
       
      Use both attributes for cases where browser/OS/screen-reader combinations don't support WAI-ARIA.
Vernon Fowler

Inclusively Hidden | scottohara.me - 0 views

www.scottohara.me/...inclusively-hidden.html

accessibility inclusivedesign screenreaders

shared by Vernon Fowler on 02 Oct 18 - No Cached
  • 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...
  • using aria-hidden to hide content specifically from screen readers
  • Vernon Fowler on 02 Oct 18
     
    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?
Vernon Fowler

Understanding Success Criterion 2.4.7: Focus Visible - 0 views

www.w3.org/...focus-visible.html

accessibility focus

shared by Vernon Fowler on 01 Oct 19 - No Cached
  • Vernon Fowler on 01 Oct 19
     
    "Success Criterion 2.4.7 Focus Visible (Level AA): Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible."
Vernon Fowler

WebAIM: Keyboard Accessibility - 0 views

webaim.org/keyboard

accessibility testing keyboard

shared by Vernon Fowler on 02 Jun 17 - No Cached
  • Long lists of links or other navigable items may pose a burden for keyboard-only users.
  • The following best practices can facilitate efficient keyboard navigation: Provide a "skip to main content" link on the page. Use a proper heading structure. Provide ARIA landmarks or HTML5 structural elements (<main>, <nav>, etc.)
  • Vernon Fowler on 02 Jun 17
     
    "when testing with a keyboard, you are not just trying to interact with the page successfully, you also want to ensure all interactions are predictable. This requires an understanding of common keyboard interactions."
Vernon Fowler

WebAIM: Semantic Structure - 0 views

webaim.org/...semanticstructure

semantic structure headings html markup lists accessibility

shared by Vernon Fowler on 05 Feb 14 - No Cached
  • Technically, lower degree headings should be contained within headings of the next highest degree (i.e., one should not skip heading levels, such as from an <h2> to an <h4>, going down the document).
  • one should not skip heading levels
Vernon Fowler

Don't Rely on Default Browser Error Messages - Intopia - 0 views

intopia.digital/...default-browser-error-messages

accessibility forms validation HTML5

shared by Vernon Fowler on 06 Feb 19 - No Cached
  • Another issue is that the messages are temporary. As soon as you put focus on the input with mouse, keyboard or touch, the message disappears. People with cognitive impairments will find it difficult to use these, and I think anyone trying to fill in the form while they’re distracted will have trouble as well. People who rely on the keyboard for navigation (which includes both sighted users and screen reader users) will also lose these messages as they move around the form.
  • If you’re confident of your error messages, you can remove the browser validation by adding the novalidate attribute to the wrapping form element, like this: <form novalidate>...</form>
  • You can style this with CSS, using the :valid and :invalid pseudo-classes
  • ...2 more annotations...
  • Only the first error is noted with a message.
  • The rest rely on a change of border colour, which is, again, not evident to screen reader users.
  • Vernon Fowler on 06 Feb 19
     
    "When I found out the major browsers were beginning to include error validation into their support for forms, I was pretty excited. Form validation is always a fiddly part of accessibility, so I'm always looking out for ways to make it easier for developers to do properly. I read MDN's form data validation tutorial and a CSS Tricks article on client-side form validation and immediately made some test forms. Sadly, I was disappointed with the results. The default error validation in browsers is almost completely inaccessible. I was hoping we'd get default "you've forgotten to fill this in" messages that could be customised. I might have been a bit too optimistic! Validation at the browser level has many of the same issues we find at the website level."
« First ‹ Previous 101 - 120 of 122 Next ›
Showing 20▼ items per page