Skip to main content

Home/ Web Accessibility/ Group items tagged inclusive

Rss Feed Group items tagged

Vernon Fowler

The Same, But Different: Breaking Down Accessibility, Universality, and Inclusion in De... - 0 views

  • One way to put a name to this activity is to say that we are going up the mountain — in other words, moving upward is our goal. Another is to refer to reaching the summit — the destination to which we aspire. The former says, in effect, “We are gradually making our way up the hill.” The latter says, “We’re not done until we get to the top.”
  • Inclusive design is the practice of going up the mountain — we can always look for ways to include more people and situations to our designs, even if the result only gets us a few steps up the trail at a time.
  • I would go so far as to say that it’s the scope of that task — the seemingly infinite nature of including everyone — that is too big of a challenge. We aren’t all born to be mountain climbers. But together we can get a little farther up the hill, if we try.
  •  
    My post on the @adobe blog is up. It's about how I distinguish inclusive design from accessibility, and why you still need to go back and learn about universal design. https://t.co/OsjUp57F29 #a11y #inclusivedesign Great article on the nuances between A11y, Inclusive Design and Universal Design. Thanks @mattmay The Same, But Different: Breaking Down Accessibility, Universality, and Inclusion in Design https://t.co/QJIXT7y96T via @adobe
Vernon Fowler

Inclusive Design: Accessible user experiences on the web « UX Australia 2010 - 0 views

  • Understanding how to incorporate accessible design practices within a project
  • Integrating accessible, inclusive design practices throughout traditional UX research and design practices
Vernon Fowler

Command F5 Web Accessibility Project - 0 views

  •  
    "Encouraging Accessible & Inclusive Design and Development"
Vernon Fowler

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

  • 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.
  •  
    Not only argues for not using the placeholder attribute but also describes an inclusive input hint and how to code it.
Vernon Fowler

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...
  • using aria-hidden to hide content specifically from screen readers
  •  
    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

Accessibility Not-Checklist | Brewed by team Intopia - 0 views

  •  
    ICYMI: As a part of #GAAD, we launched an Accessibility Not-Checklist. It's a resource that will help any person work towards an accessible and inclusive digital user experience, no matter your level of accessibility knowledge. Check it out: https://t.co/
Vernon Fowler

RGD Launches Best Practices Handbook at DesignThinkers 2010 | Access Ability - 0 views

  • Available in both printed and accessible pdf formats, the handbook is free to anyone interested in designing more accessible and inclusive communications. Covering print, web and environmental design, it offers ideas on how to do better design – what factors to consider, what questions to ask, and where to find more information.
Sandra Earl

Designing and Developing mobile web sites in the real world, part 2 - Opera Developer C... - 0 views

  • In tandem with the launch of their 3G mobile website, Siminn also launched a slightly lighter version of the same site - a 2G-optimized mobile presence to serve less powerful phones. Both sites are anchored to the same reservoir of information, but the 3G site makes less-restricted use of CSS, images, and other coding ornamentations.
  • The only distinction Siminn makes concerning the dimensionality of the user-experience is whether the device is 2G or 3G enabled. As stated before, 2G devices are sent to a slightly lighter version of the 3G site
  • This is exactly what Siminn are doing. By detecting the type of phone, they are presenting the customer with the most appropriate version of the page – either the 3G enhanced or the more basic design.
  • ...19 more annotations...
  • e chose not to try and replicate the entire Icelandair website, but rather to cleave from it four or five of its most crucial elements.
  • This page contains the only form on the mobile site. In general, forms should be avoided because form input via a mobile device can be a tricky endeavor. However, there are certain coding practices that can simplify form input. For example, if your form field should only accept numeric input, then you should make use of the -wap-input-format property of WAP CSS. The Apple iPhone will automatically set the input to numeric if the name of the input element is set to certain values - phone or zip for example.
  • Mobile users only need to be shown news items that have some inherent urgency.
  • Much like your desktop browser recognizes a mailto: link as an email address, mobile devices recognize tel: links and phone numbers.
  • Do not assume that just because the UA string is not in your enumerated list of “Accepted strings”, it is not possible to view the site.
  • This is where you build in progressive enhancements to the website experience.
  • WURFL is an open source list of known phones and their capabilities. This can be put into a database and when a mobile device visits the your site you can sniff the UA, look-up the capabilities of that device (including screen-dimensions, default browser, etc) and serve them the best possible experience.
  • The RDF vocabulary is a standard across many mobile devices. Vendors that use this approach allow mobile sites to keep up-to-date with any new devices, without having to keep their own database of device types.
  • ou can find more details about standards support in Opera Mini/Mobile 4 here: Designing with Opera Mini 4 in mind JavaScript support in Opera Mini 4
  • There are a few basic coding items to avoid in the mobile web space. Chief among these, at least for now (now being 10/2007), is client-side scripting.
  • While it's tempting to try and port that elegant bit of AJAX from your conventional web to your mobile web, you will only create headaches for yourself.
  • ome browsers do support various levels of JavaScript, but as a developer you should not expect it to work across all devices.
  • retty heavy processor hog, so continuous scripting can drain a battery fast
  • mobile browser support for stylesheets varies greatly.
  • keep things simple.
  • most mobile devices default to their own font sizes and families regardless of styling. Thus, when working on the Siminn project we made no attempt to influence font size or family. In cases where we wanted a larger font, we simply relied on the generic XHTML heading elements.
  • he inclusion of font-size=smaller in the body tag worked as a kind of global reset for font sizes in every device we tested. With this little bit of code we were able to sufficiently reduce the default font size and thus more faithfully reproduce the design that we had been tasked with coding.
  • XHTML-MP - the mobile web subset of XHTML - is fully supported on most modern devices.
  • You can't read 2 books and several articles about mobile web development and cover everything. Much of the effort is trial and error. When starting out, emulators are a good way to get a rough idea of how the site will work. It gives you some feel for the navigation, architecture and flow of the site, but the look and feel varies from the emulator to the real device. The best thing you can do is get a few real phones to test on. I'm sure between yourself, co-workers and a few friends, you can manage to test your site on a good cross-section of the phones out there. Finally, there is some help. The W3C mobile web initiative does have a checklist to see how well your site is doing and so does dev.mobi - if you take heed of these two lists, your site should give a quality experience to most customers.
Sandra Earl

E-Access Blog » Blog Archive » Global Online Accessibility Resource Set For 2... - 0 views

  • An online resource of open source, royalty-free assistive technology tools, accessible and usable at any time and across the world, is to be launched next year by a consortium of more than 30 US and European IT and disability organisations and leaders, the European Commission e-Inclusion conference heard this month.
Vernon Fowler

How To Force Subtitles In An Embedded YouTube Video - 0 views

  • To enable subtitles by default, you will need to use &cc_load_policy=1 parameter
  • 3. Linking to Videos with Captions If you want to share a link to the video for viewers to see captions by default, you need to add this code at the end of the URL string: &yt:cc=on
  • &yt:cc=on
    • Vernon Fowler
       
      If there aren't any existing URL parameters, instead of appending &yt:cc=on you may need to use /?yt:cc=on For example https://youtu.be/GUfCPMCMORM/?yt:cc=on
1 - 18 of 18
Showing 20 items per page