Skip to main content

Home/ Web Accessibility/ Group items tagged javascript

Rss Feed Group items tagged

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

Unobtrusive and keyboard accessible connected select boxes | 456 Berea Street - 0 views

  • Any web developer who has created a reasonably complex form is probably aware of the concept of multiple select elements that are connected – choosing something from one select box either makes a new select box appear or changes the options of one that is already visible. There are usually two problems with this approach. One is that most implementations are completely dependent on JavaScript being available. Often there either is no submit button at all, or there is a submit button but without JavaScript there is no way to access the options that appear only as a result of changing the first select box. The other problem is that in some browsers, using the cursor keys to change the selected option triggers the onchange event immediately, so you can never get past the first option unless you know how to use your keyboard to display all options. I normally work around these problems by requiring users to submit the form to get the next set of options from the server. Obviously that isn’t an ideal solution either. So what other options do we have? One option that looks promising is described by Christian Heilmann in Unobtrusive connected select boxes - yet another solution approach. It involves using optgroup elements to create a two-level select box, which is then split into two separate select boxes if JavaScript is available. Neat. The solution Chris describes solves (or at least mitigates) the keyboard access problem since it doesn’t reload the page when the onchange event is triggered. And if JavaScript is unavailable, there is a single select box with option groups. The catch is that nested optgroup elements are not allowed in current versions of HTML, so this will not work when more than two connected select boxes are needed. Nested optgroup elements are allowed in the current Web Forms 2.0 Working Draft, so I guess there is a reasonable chance of that change making it into HTML 5.
Vernon Fowler

HTML_CodeSniffer - 0 views

  •  
    HTML_CodeSniffer is a client-side script that checks HTML source code and detects violations of a defined coding standard. HTML_CodeSniffer is written entirely in JavaScript, does not require any server-side processing and can be extended by developers to enforce custom coding standards by creating your own "sniffs". To get you started, HTML_CodeSniffer comes with standards that enforce the three conformance levels of the Web Content Accessibility Guidelines (WCAG) 2.0, and the web-related components of the U.S. "Section 508" legislation. An auditor interface is provided by a bookmarklet to let you try out these accessibility checks on any web page.
Sandra Earl

E-Access Blog » Blog Archive » Organisation in the Spotlight - W3C: Global St... - 0 views

  • One major new piece of work undertaken by WAI is the EC-funded WAI-AGE Project (http://www.w3.org/WAI/WAI-AGE/), a look at the implications of an ageing population for web access, given the older people are more likely to have disabilities and may also be less familiar with new technologies. “Demographics worldwide are dramatically changing at the moment,” says Andrew Arch, who works with Abou-Zahra on WAI-AGE. “The proportions of older to younger people are changing as well as the numbers. We’re living longer, and we haven’t got the support behind us. “Lots of things have got to change in governments and organisations - with an ageing workforce, you have to keep learning to stay accessible.”
  • The WAI-AGE project is partly aimed at finding out whether there are any significant new pieces of work needed to ensure web accessibility for an older population, Arch says. “We’ve looked at what research and user observation has gone on over the decade. There is a pretty big overlap between older people and others with disabilities - sight starts to decline, motor dexterity - and individually these overlap. But with older people there is often a lack of recognition that there is a disability there. For example some people might just say they can’t remember so well, rather than that they have a cognitive impairment. Or people won’t see failing eye-sight as a disability, it’s just ‘part of growing old’. But they are disabilities, and often multiple disabilities.”
  • Having gained a grasp of current research the project returned to guidelines such as WCAG 2.0 to see if any changes might be needed. “A large proportion of the needs of older people are met by the new guidelines, but other things might need to feed into the guidance we will issue on implementing the guidelines, for example guidance on how people prepare content for older people.,” said Arch. “Many older people have not grown up with computers, and may not realise their capabilities, for example that you can magnify text in your browser.”
  • ...4 more annotations...
  • This argument is a development of the age-old mantra from the accessibility sector that people with disabilities want to use the web in the same way as everybody else - “it is a human right recognised by the UN,” says Abou-Zahra. But he recognizes that businesses in particular will also  be interested in the additional business benefits, especially in the current financial climate.
  • “With commercial organisations the return on investment is often an important argument. Well, a few years ago, companies might have said ‘how many older people are online?’ but with demographics changing they know the answer. And with the current surge in mobile phone use there is another incentive, since accessible sites work better on mobile phones.”
  • Another change of style will be a greater separation between the core guidelines and references to specific technologies such as Javascript or browser types, Abou-Zahra says.
  • “WCAG 1.0 was too  technology-specific. Back then HTML was more dominant, and there was less use of multimedia, but today we have a flurry of technologies such as Ajax, so the first lesson we learned is don’t write for a specific technology. Also, in the days of WCAG 1.0 we had to exclude Javascript because it was not sufficiently standardised and  assistive technology could not handle it consistently, but now that has largely changed so you need to include it, to look at how any technology should be accessible. The requirements - such as tagging images with text - needs to apply to any technology you are using.
Sandra Earl

WebAIM: Accessibility of AJAX Applications - Accessibility Issues - 0 views

  • AJAX is
  • a smorgasbord of web technologies put together to allow dynamic client-server interactions to occur in web applications without requiring pages to reload or refresh.
  • AJAX uses the following:
  • ...13 more annotations...
  • The XHTML and CSS elements can be dynamically modified to display new information or styling. These changes are typically done using the Document Object Model.
  • XHTML (or HTML) and CSS to create an interface and visually style information.
  • JavaScript is used to manipulate the interface elements and is also used to establish a communication with a web server through XMLHttpRequest. This allows data (typically in XML format) to be transmitted between the client and the web server without requiring page reloads or refreshes.
  • standard type of client-server interaction
  • A web page interface is presented. User information is collected (via forms, links, etc.). The user submits information (submits form, activates link, etc.). The server processes submitted information. A new web page interface is sent to the user.
  • With AJAX, all of these steps can be handled in one interface.
  • The types of web applications and interactions allowed by using AJAX has given rise to the term "Web 2.0"
  • AJAX allows feature-rich, dynamic web applications which use server-side processing without requiring the traditional "submit data — retrieve web page"
  • allows more streamlined applications that require less processing and data transmission
  • higher levels of interactivity
  • current solution to these problems is to either provide a non-AJAX alternative to your application or to allow your AJAX application to continue to function if JavaScript and XMLHttpRequest are not supported. Such a requirement may be very difficult to achieve
  • Another issue with AJAX is how the application interface is updated. When updates to the interface occur, it may not be visually apparent that a change has occurred. The problem is even more troublesome for screen reader users. Screen readers typically read in a linear fashion. When changes happen in the interface, the screen reader user may not be aware of the change and the new content will likely not be read.
  • to allow dynamic interface changes to be accessible, the application must alert the user that a change has occurred, allow direct access to the new content, and then allow continued functionality of the web application. This process, while difficult to achieve, especially for screen reader users, is possible to achieve in many AJAX applications.
Vernon Fowler

A List Apart: Articles: Now You See Me - 0 views

  • visibility: hidden; Element is hidden from view, but is not removed from the normal flow (i.e., it still takes up the space it normally would) Content is ignored by screen readers display: none; Element is removed from the normal flow and hidden; the space it occupied is collapsed Content is ignored by screen readers height: 0; width: 0; overflow: hidden; Element is collapsed and contents are hidden Content is ignored by screen readers
  • if you want to ensure users have access to content (even if it isn’t displayed visually in the current interface), the final option (positioning content offscreen) is really the way to go.
  • Screen readers have access to the content
  • ...6 more annotations...
  • position: absolute; left: -999em;
  • but links may “focus” oddly and negative indent may not prove long enough to fully hide content
  • limited to text and inline elements
  • Content is removed from the normal flow and shifted off the left-hand edge; the space it occupied is collapsed
    • Vernon Fowler
       
      This is usually my desired effect.
  • If you don’t want your hidden content to be read by a screen reader, those defaults may work for you
  • how profoundly your choice of hiding mechanism can influence the accessibility of your content to assistive technologies like screen readers
Vernon Fowler

How Can I Validate (X)HTML + ARIA? | The Paciello Group BlogThe Paciello Group Blog - 0 views

  • The DTD I have used is the HTML 4.01 loose DTD with ARIA attributes added
  • A way I have developed to do this is by creating a bookmarklet that takes the innerHTML of a document (without the DOCTYPE) and adds the custom DOCTYPE to it and then sends it to the W3C validator: HTML4.01-loose+ARIA Checker (add as a favorite to try it out)
Sandra Earl

97% of websites still inaccessible | 456 Berea Street - 0 views

  • United Nations Global Audit of Web Accessibility, conducted by accessibility agency Nomensa on behalf of the United Nations, shows that 97 percent of websites fail to meet the most basic accessibility requirements.
  • A story on the BBC News website, ‘Most websites’ failing disabled, notes that 93 percent did not provide alternative text for all images, 73 percent relied on JavaScript for important functionality, and 98 percent of the sites did not use valid markup.
Sandra Earl

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

  • 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 - 20 of 26 Next ›
Showing 20 items per page