Skip to main content

Home/ Web Accessibility/ Group items tagged practices

Rss Feed Group items tagged

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

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.
Vernon Fowler

Joe Dolson: Accessibility And WordPress: Developing For The Whole World | WordPress.tv - 0 views

  •  
    This presentation covers accessibility topics including implementing best practice accessibility for theme and plug-in developers, discussing current progress and goals from the WordPress Accessibility P2 group, and addresses general principles of accessibility useful for every WordPress developer and designer.
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

Better Website Development: Disability Discrimination Act Dda Amp Web Accessibility - 0 views

  • There's been widespread speculation about the new legislation being introduced under the DDA (Disability Discrimination Act), which will ensure that websites are accessible to blind and disabled users. Try to find specific information about it on the Internet and chances are you'll come up empty handed.The RNIB (Royal National Institute for the Blind) and the DRC (Disability Rights Commission), two of the most renowned advocates for the DDA (Disability Discrimination Act) and accessible websites, have no specific information about the laws and what websites specifically need to do in order to meet the legal requirements.
  • 2.2 (p7): "The Act makes it unlawful for a service provider to discriminate against a disabled person by refusing to provide any service which it provides to members of the public."
  • 4.7 (p39): "From 1st October 1999 a service provider has to take reasonable steps to change a practice which makes it unreasonably difficult for disabled people to make use of its services."
  • ...2 more annotations...
  • The law about accessible websites came into force on 1st October 1999 (http://www.drc-gb.org/open4all/law/code.asp) and the Code of Practice for this section of the Act was published on 27th May 2002 (http://www.hmso.gov.uk/si/si2002/20020720.htm). This means that the majority of websites are already in breach of the law.Can you be sued?Well, probably. The RNIB claim that they've considered taking up a number of legal cases against organisations with regard to their websites. When they raised the accessibility issues of the website under the DDA, companies have typically made the necessary changes, rather than facing the prospect of legal action.The DRC has now published their findings from their formal investigation into 1000 websites. (http://www.drc-gb.org/publicationsandreports/2.pdf). If your website was included then you will have to start thinking about making it accessible to all web users in the very near future.
  • What do you need to do to comply?It's widely believed that if, or perhaps more appropriately when, a case makes it to court that the W3C accessibility guidelines will be used to assess a website's accessibility and ultimately decide the outcome of the case. The W3C is the Internet governing body and its web accessibility guidelines can be found at http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html.
Vernon Fowler

6 Surprising Bad Practices That Hurt Dyslexic Users - UX Movement - 0 views

  • many dyslexic users are sensitive to the brightness the high contrast colors cause
  • use an off-white color for your background, like a light gray or tan. You can also use a dark gray for your text instead of pure black to cut the glare even more
  • dyslexic users need more breaks between ideas than non-dyslexic users
  • ...4 more annotations...
  • Breaking up your text to one idea per paragraph makes reading a lot easier for both dyslexic and non-dyslexic users.
  • a sans-serif font would allow dyslexic users to see the shapes of letters clearer
  • you shouldn’t use italicized text because they make letters hard to read
  • avoid creating the river effect by using left aligned text, instead of justified text for your paragraphs
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

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

  • 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

WebAIM: Appropriate use of alternative text - 0 views

  • It is read by screen readers in place of images allowing the content and function of the image to be accessible to those with visual or certain cognitive disabilities. It is displayed in place of the image in user agents (browsers) that don't support the display of images or when the user has chosen not to view images. It provides a semantic meaning and description to images which can be read by search engines or be used to later determine the content of the image from page context alone.
  • The first step when determining appropriate alternative text for an image is to decide if the image presents content and if the image has a function. In most cases, an image will only have a function if it is contained within a link.
  • NOT use the phrases "image of ..." or "graphic of ..." to describe the image.
  • ...14 more annotations...
  • NOT be redundant or provide the exact same information as text within the context of the image.
  • (no alt attribute) is never the right choice
  • When possible, avoid using "link to" or "click this image" or similar wording in the alt attribute. Links are identified as links by screen readers and should be visually apparent to sighted users.
  • Decorative images do not present important content, are used for layout or non-informative purposes, and do not appear within a link. In almost all cases, spacer and decorative images should have null alt text (alt="").
  • Option C (alt="") would be most appropriate in this case because the image does not convey relevant or important content.
  • Form image buttons must have an alt attribute that describes the function of the button. Image buttons are often used to provide a more visually appealing or a smaller version of the standard form buttons. The alternative text should describe what the button will do when selected, such as "Search", "Submit", "Register", "Place your order", etc. For instance, <input type="image" alt="Submit Search"> might be appropriate for an image button on a site search form.
  • text must be provided to the user which presents the CONTENT and FUNCTION of the images within your web content
  • In many cases, images may be given an empty or null alt attribute (e.g., alt="").
  • Option B is the best choice - it clearly provides the content that is being presented by the image - that the link is to a PDF file.
  • Because this is fairly standard practice, providing alternative text for the image, such as your company name (alt="Acme Company), will usually suffice.
  • It is important to note here that if the icon itself were the link to the document, the alternative text should provide a full alternative of the content and function of the link/image combination. Something like, "Download the employment application in PDF format".
  • Alternative text should: presents the CONTENT and FUNCTION of the image. be succinct.
  • Alternative text should not: be redundant (be the same as adjacent or body text). use the phrases "image of…" or "graphic of…".
  • Alt text of a functional image (e.g., an image within a link) should describe the function as well as the content.
Vernon Fowler

WordPress › WP Accessibility Plugin « Make WordPress Accessible - 0 views

  • These title attributes have exactly the same value as the text of the link — if the text of the link is “Joe’s Blue Widgets”, then the title attribute is also “Joe’s Blue Widgets”. In the best case scenario, where a screen reader is set up to ignore title attributes, having this set makes little difference. In the worst case scenario, where a screen reader reads all attributes, it’s awful: the screen reader reads the title attribute and the link text, meaning that every link is, effectively, read twice.
  • Skiplinks provide a means to leap from the very top of a page to an alternate section of that page — one principle use being to leap over the main navigation to the main page content.
  • It does *not* remove it from other fields, because a common technique to grant keyboard focusability to normally non-focusable elements is to define a negative tabindex: this places the element into the focus sequence but does not force it into a particular place in that sequence.
  • ...5 more annotations...
  • Removing those attributes usually makes keyboard navigation much more linear and predictable. The intention behind tabindex was to create a logical tab sequence when it would otherwise have been unnatural; but in practice, that required absolutely insane degrees of maintenance to use in a real-life web site.
  • Links opened in new windows can break web site flow (creating a change of context) and disorient users who don’t realize they’ve moved to a new window. Also, it takes away the option of opening in the same window/tab
  • Remove title attribute from inserted post images/featured images
  • for accessibility, all links should make sense without requiring context, to grant screen readers the ability to scan the page and have information. This plug-in adds the title of the post into this pattern
  • Many designs do not provide a design for the view of links or other focusable fields when a keyboard user brings focus to that element. This makes it very difficult for visual users who are keyboard dependent to keep track of where they are. A common pattern for this is to change the appearance of the element on keyboard focus; and this item adds an outline.
Vernon Fowler

WebAIM: Alternative Text - 0 views

  • Alternative text should not: be redundant (be the same as adjacent or body text). use the phrases "image of…" or "graphic of…".
  • Identifying the logo as actually being a logo (alt="Acme Company Logo") is not typically necessary.
  • If the fact that an image is a photograph or illustration, etc. is important content, it may be useful to include this in alternative text.
  • ...4 more annotations...
  • Decorative images do not present important content, are used for layout or non-informative purposes, and do not appear within a link. In almost all cases, spacer and decorative images should have null alt text (alt="").
  • In current practice on the web, many such images are given descriptive alternative text even though the images don't seem to provide useful content. Option C (alt="") would probably be most appropriate in this case because the image does not convey relevant or important content.
  • Alternative text should: presents the CONTENT and FUNCTION of the image. be succinct.
  • Decorative images still need an alt attribute, but it should be null (alt="").
1 - 20 of 39 Next ›
Showing 20 items per page