Skip to main content

Home/ Web Accessibility/ Group items tagged progressive enhancement

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Sandra Earl

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

dev.opera.com/...d-developing-mobile-web-site-1

accessibility mobile opera best practices reading

shared by Sandra Earl on 12 Oct 10 - Cached
  • 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.
Vernon Fowler

Creating an Accessible Infographic | Access Matters Blog - 0 views

www.interactiveaccessibility.com/...reating-accessible-infographic

infographic accessibility html markup css progressive enhancement

shared by Vernon Fowler on 25 Feb 14 - No Cached
  • Screen readers are very literal and, as such, tend to read out numbers in a list with no particle words or punctuation.
  • Using a CSS technique to position text off the screen, it’s simple to add some particle words (such as “from” or “to”) for screen reader users. In the case of a range of numbers, the dashes can be presented using graphics and not part of the text content of the page. For example, in the second data point shown in the image below, instead of a screen reader announcing “twenty-six percent fifty-five sixty-four” it would be “twenty six percent fifty-five to sixty-four.”
  • Another example is implied headings. Sighted users can understand quickly from images that a data set title should be “gender” but if the heading doesn’t appear in the design, it should be added and visually hidden using CSS.
Sandra Earl

The Dutch accessibility law is awesome | 456 Berea Street - 0 views

www.456bereastreet.com/...h_accessibility_law_is_awesome

accessibility laws standards

shared by Sandra Earl on 12 Oct 10 - Cached
  • New Dutch accessibility law.
  • A few highlights of what is required: separate structure from presentation do not use deprecated markup when creating a new website, use a Strict doctype use progressive enhancement create semantic class and id values use the W3C DOM when scripting script-only links must be generated by JavaScript do not use the alt attribute to create tooltips
1 - 4 of 4
Showing 20▼ items per page