Skip to main content

Home/ Web Accessibility/ Group items tagged help

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.
Sandra Earl

Forget WYSIWYG editors - use WYSIWYM instead | 456 Berea Street - 0 views

www.456bereastreet.com/...yg_editors_use_wysiwym_instead

accessibility WYSIWYG

shared by Sandra Earl on 12 Oct 10 - Cached
  • A huge problem with almost every CMS in existence is the extremely poor quality of the code produced by their WYSIWYG editors.
  • Since visual gadgetry like WYSIWYG editors sells, every CMS has to have one.
  • That, in turn, makes it necessary for Web professionals who want to reduce the risk of clients unknowingly ruining the website’s semantics and accessibility to disable features and implement more or less advanced code cleaning procedures. It is a mess.
  • ...4 more annotations...
  • Because of the problems caused by WYSIWYG editors I have toyed with the idea of providing a much simpler interface for content editors. Markdown, BBCode, and Textile are a few possible solutions that ensure valid markup and increase the likelihood of it being semantic. The problem would be making clients accept working that way, directly editing pseudo markup. Most clients wouldn’t, so that option is ruled out.
  • But there is another kind of editor that is better suited than WYSIWYG for content-driven, client-edited sites - the WYSIWYM (What You See Is What You Mean) editor. In Visually Editing Semantics - What You See Is What You Mean, Peter Krantz mentions one such editor: WYMeditor.
  • From the WYMeditor site: Our goal is to create a XHTML strict web-based editor which will be usable on many platforms, whith the help of the Open Source Community.
  • There are a few limitations, of course. This is an early version, after all. Besides the issues Peter notes in his post about WYMeditor, here are a few more things I noticed: Table accessibility. There is no way to add elements and attributes (th, caption, scope, etc) needed for accessibility to data tables. Table resizing. It is possible to size tables by dragging handles. Doing so is reflected in the markup. That needs to be filtered out at some stage before saving the page to the database. Incorrect nesting of lists. When you create nested lists, the current list element is closed before the next level ul or ol is inserted.
Sandra Earl

Multiple form labels and screen readers | 456 Berea Street - 0 views

www.456bereastreet.com/...form_labels_and_screen_readers

accessibility forms labels JavaScript alerts

shared by Sandra Earl on 12 Oct 10 - Cached
  • Well, it turns out you can do that. From The LABEL element in the HTML 4.01 specification: The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control. The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute. Sounds great, doesn’t it? A quick check in graphical web browsers shows that they associate multiple labels with the input field (as evidenced by the input field gaining focus when either label is clicked). But what about screen readers? It would be so useful if this would work… Unfortunately, and perhaps unsurprisingly, it looks like it doesn’t quite work as well as you’d hope. I mentioned this briefly in Use the label element to make your HTML forms accessible, but I think it’s worth bringing up again since full support for multiple labels would help us make forms more accessible to screen reader users while keeping visual designers happy. I am far from an expert user when it comes to screen readers, but I’ve done some limited testing with mostly disappointing results. Apple VoiceOver does not recognise more than one label element associated with a form control and reads only the label that comes first in the document’s source order. JAWS and Window-Eyes both do the opposite and read only the last label when an input field gains focus. The only screen reader of those that I tested that does handle multiple labels is Fire Vox. The exact results may obviously depend on user configuration and reading modes, and there may be other screen readers that get it right, but these results indicate that screen reader behaviour is too inconsistent for multiple labels to be a reliable technique.
Sandra Earl

BBC Internet Blog - 0 views

www.bbc.co.uk/...free_range_widgets.html

adobe air accessibility online help

shared by Sandra Earl on 12 Oct 10 - Cached
  • We considered a few approaches, but decided to grow our new widget out of Adobe Flex and Adobe AIR. This is firstly because these tools met our requirements to work cross-platform and deliver the desktop experience we wanted, and also because they linked up with in-house skills in the team which manages them, making them simpler to manage.
  • BBC Future Media & Technology's pilot widget application BBC LiveUpdate uses the Adobe AIR runtime, which is dependent on users downloading and installing a plugin to their desktop, but which unfortunately does not currently support screenreaders (or other software which relies on the Microsoft Active Accessibility layer for assistive technologies). We're working with Adobe to make tools built with AIR more accessible than current products wherever possible and are committed to delivering accessible services. As this is a beta product, there are also other limitations in how much we have been able to establish accessibility support in the following areas:Colour contrast cannot be alteredText size cannot be alteredLacks consistent alt textLacks Title attributesIs not entirely tabbable.
Sandra Earl

Designing for Dyslexics: Part 3 of 3 - Accessites.org - 0 views

accessites.org/...ning-for-dyslexics-part-3-of-3

accessibility cognitive learning disabilities dyslexia

shared by Sandra Earl on 12 Oct 10 - Cached
  • Shorter line lengths and narrower text columns make reading easier.
  • Consider setting a percentage width for text areas and set the margins to “0 auto” via CSS. The page side margins will then increase proportionately on wider screens.
  • Most browsers have a default line-height of around 1em. This normally results in closely packed lines of text. Increasing the line-height to around 1.3em immediately makes longer lines of text easier to read. Likewise, ensure that paragraphs are visibly separated. Don’t be afraid of white space. Use it to enhance readability.
  • ...16 more annotations...
  • percentages or ems.
  • If possible, use a sans-serif font. The decorative “hooks” on the main strokes of serif letters may create additional problems for dyslexic users.
  • If you have to use a corporate serif font, consider reducing the letter-spacing slightly so that the letters within a word lie closer together but increasing the word-spacing to create a slightly larger distance between individual words.
  • uneven word spacing disrupts that pattern recognition.
  • Unjustified text, although less attractive at first glance. is far easier to read.
  • When italic fonts are used on a web page, the individual letters can have a slightly jagged line compared to a non-italic font. This “pixelation,” coupled with their “lean to the left” makes them hard for a dyslexic person to read. The effect is compounded if the text is also small.
  • Use italics sparingly and consider bold text for important words. They’ll be far easier to read.
  • Photographs, charts and icons can convey a great deal of information regarding the topic of a page. Graphics can break the page up into smaller chunks. They can also provide visual memory aids and support comprehension for dyslexics.
  • Dyslexics often have poor organisational skills. Lists can help them by organising information into small, logical chunks.
  • Dyslexics tend to have poor information processing skills. So it is relatively easy to overload them by literally providing too much information on one page.
  • Within a page, use headings to sub-divide the page logically and visually. Adding coloured heading backgrounds or borders will act as further support.
  • Consider breaking complex pages down into two or three smaller pages.
  • Keep site navigation simple and logical. Make sure that the Home page is easily reachable from any part of the site. Try not to “hide” this important link in a logo.
  • break long sentences down into two or more shorter sentences
  • Many designers do not realise that some screen reader users can see perfectly well. It is not uncommon for dyslexics to use screen readers to support their reading. This may create problems where text has been positioned off screen.
  • If you do make use of off screen positioning, try to do so sympathetically. Consider the viewpoint of those who can both hear the screen reader and see the page. Ask yourself if you’re potentially creating confusion.
Sandra Earl

Web Axe - Practical Web Design Accessibility Tips - Podcast and Blog: Paul Boag wears r... - 0 views

webaxe.blogspot.com/...wears-reading-glasses-and.html

accessibility general elderly FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • In Boagworld podcast episode 130, I discovered that in order to help test web accessibility, Paul Boag wears glasses (that he doesn't need) and gloves and attempts to navigate through a site. Excellent idea!In order to better understand [the elderly's] experience I have bought a pair to ski gloves and some reading glasses (I don't need reading glasses). Every now and again, I surf the site I am designing wearing both the glasses and gloves. The glasses make the screen hard to read while the gloves hamper my use of the mouse and the keyboard. There is nothing more frustrating than trying to select something from a drop down menu wearing ski gloves!
Sandra Earl

WebAIM: Screen Reader Survey Results - 0 views

webaim.org/...screenreadersurvey

accessibility vision blindness screen reader WebAIM general FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • We received 1121 valid responses to the screen reader survey, which was conducted Dec. 2008 - Jan. 2009.
  • Skip to content22% Skip to main content28%
  • 33 respondents (2.9%) reported being both deaf and blind.
  • ...33 more annotations...
  • Please rate your computer proficiency Response% of Respondents Expert22% Advanced44% Intermediate27% Beginner8%
  • Please rate your screen reader proficiency Response% of Respondents Expert17% Advanced41% Intermediate32% Beginner9%
  • Screen Reader Usage
  • Of the 1121 respondents, 74% use JAWS, 23% use Window-Eyes, 8% use NVDA, and 6% use VoiceOver. While several other screen readers were reported, these were the most prominently reported. Individual versions of screen readers are not yet computed, but generally the majority of users are using the most up-to-date version of their screen reader.
  • How soon do you update your screen reader after a new version is released? Upgrade Window% of Respondents Immediately41% First 6 months25% 6-12 months9% 1-2 years9% 2-3 years4% 3+ years6% No response6%
  • How customized are your screen reader settings? (e.g., changed verbosity, installed scripts, etc.) Response% of Respondents A lot29% Somewhat40% Slightly21% Not at all7% No response4%
  • a lot or some customization was reported by only 27.6% of respondents with no disability versus 71.4% for those that reported blindness.
  • 78% of respondents reported using a screen reader on a desktop computer, 54% use a screen reader on a laptop, and 12% use a screen reader on a mobile phone.
  • No respondents who use screen readers for evaluation reported using a screen reader on a mobile device.
  • Which web browser(s) do you currently use with a screen reader? Browser% of Respondents IE633% IE768% IE82% Firefox39% Safari6%
  • Respondents with no disability were nearly twice as likely to list Firefox as blind respondents - 66% to 37%.
  • The percentage of Safari users is over double that of the overall population - this may be due in part to the fact that some in the Mac community actively solicited survey participation and encouraged respondents to indicate their Safari use, perhaps partially due to feeling snubbed because we didn't list them with IE and Firefox as direct choices.
  • When first accessing a new, unfamiliar home page, I'm most likely to... Response% of Respondents Read through the home page46% Navigate through or listen to the links on the page35% Use the Search to find what I'm looking for13% Look for a site map or site index3% No Response2%
  • Interestingly, the more proficient screen reader users are more likely to read through the home page and use links less often than less proficient screen reader users. This may be due to faster reading speeds for more experienced users. The home page strategies used were very similar regardless of proficiency, disability, or amount of screen reader use.
  • I use "skip to content" or "skip navigation" links... Response% of Respondents Whenever they're available22% Often16% Sometimes28% Seldom19% Never10% No Response4%
  • Some questions were of a technical nature and we understand that many participants may not have been very technically savvy. Responses may also be based upon user experiences with web content that is generally inaccessible. We cannot help but wonder if responses may have been different if screen reader interactions with web content were typically very positive.
  • I use Access keys... Response% of Respondents Whenever they're available22% Often16% Sometimes28% Seldom19% Never10%
  • I navigate by headings... Response% of Respondents Whenever they're available52% Often24%
  • 76% always or often navigating by headings when they are available.
  • I use site search functionality... Response% of Respondents Whenever it's available26% Often25% Sometimes31%
  • Find the word "Search"18% Jump to the first text/edit field on the page25%
  • Jump to the first form element in a page36%
  • Proficient screen reader users were more than twice as likely to jump directly to the form or text/edit field than less proficient users. Less proficient users were nearly three times more likely to use more manual methods (reading, tabbing, or finding) than more proficient users.
  • a majority of respondents seldom or never use site maps. There was no marked difference in the use of site maps across screen reader proficiency or disability. In general, it appears that site maps may be beneficial, but are not commonly accessed by screen reader users.
  • Text-only versions are always used by many and never used by many. As such, it is very difficult to interpret the value they have for screen reader users. More proficient screen reader users were much less likely to use text-only versions than less proficient users. This may suggest that proficient users employ sufficient techniques to render the main version acceptable to them. Or, it may suggest that proficient users do not gain value in using text-only versions, which are often less than optimal.
  • If content is identified as being "for screen reader users", how often do you use it? Response% of Respondents Whenever it's available38% Often15% Sometimes25% Seldom13%
  • A closer analysis, however, reveals that pop-up windows are reported as very difficult twice as often by less proficient screen reader users than with higher proficiency. Alternatively, more proficient users were three times more likely to indicate that pop-up windows are not at all difficult. This shows that less proficient screen reader users (which represent 41% of respondents) have more difficult experiences with pop-up windows.
  • Firefox users were much more likely to give a favorable response, perhaps a reflection of Firefox support for ARIA, etc. Evaluators and those without disabilities were nearly twice as likely to indicate that these applications are not very or not at all accessible than those that always use screen readers or have disabilities. This may suggest that these applications are actually more accessible than evaluators believe them to be, or alternatively, that screen reader users with disabilities are less knowledgeable about the true inaccessibility of these technologies.
  • 66% of evaluators preferred that the image be ignored, compared to only 28% of those that always user a screen reader. Similarly, 65% of those with no disability preferred that the image be ignored, compared to 29% of those with disabilities.
  • If a web page contains a photo of the White House, I prefer that the image be identified as... Response% of Respondents Photo of the White House80%
  • 69.4% of evaluators found them difficult compared to only 42.6% of those that always use a screen reader. Those with higher screen reader proficiency naturally found these links easier.
  • 71.5% of screen reader users reported that Flash is difficult
  • While the majority (58%) of users reported that frames are easy, those that are blind were 3 1/2 times more likely to indicate that they are easy than those with no disability. Similarly, those that always use a screen reader reported frames as easy nearly 3 times more often than evaluators. This perhaps suggests a misconception among those that do not have disabilities that frames are very inaccessible when in fact those with disabilities find them easy.
Sandra Earl

InformIT: The Adobe AIR Platform: Software Revolution or Evolution? > The Adobe AIR Pla... - 0 views

www.informit.com/...article.aspx

accessibility adobe adobe air online help

shared by Sandra Earl on 12 Oct 10 - No Cached
  • Adobe AIR is a cross-operating system platform that allows developers to leverage their existing web development skills in HTML, Ajax, XML, Flash and Flex to build and deploy Rich Internet Applications for the desktop.
Sandra Earl

Adactio: Journal-Tools and Technologies to Watch and Avoid - 0 views

adactio.com/1456

accessibility adobe air online help

shared by Sandra Earl on 12 Oct 10 - Cached
  • Christian asks what would be the open-source equivalent of AIR? XUL says Ian. Christian says that AIR is built on HTML, CSS and JavaScript so once the player gets keyboard access it will be quite accessible. Ian responds that he looked on the Adobe site for accessibility info on AIR and the fact that he found nothing scared him.
Sandra Earl

Tim Anderson's ITWriting - Tech writing blog » Adobe AIR: 10 reasons to love ... - 0 views

www.itwriting.com/...-it-10-reasons-to-hate-it.html

accessibility adobe air online help

shared by Sandra Earl on 12 Oct 10 - Cached
  • 3. Easy conversion of existing Flex or HTML applications. It’s the same basic runtime. In the case of HTML, AIR apps rely on WebKit, the core component in Apple’s Safari web browser.
  • 7. Rich design and multimedia. This is Flash, so ideal for highly customized UIs, animation, sound and video. Adobe is proving the point by creating a media player built with AIR. Existing Flash developers can easily use their skills to build AIR applications.
  • 4. Proprietary technology. AIR applications depend on Adobe’s runtime.
  • ...3 more annotations...
  • 6. No model for commercial components. It is not clear to me how a component vendor could sell an AIR component while protecting it from unlicensed deployment. This may limit the availability of 3rd party components, with a corresponding impact on productivity.
  • 7. Schizophrenic development model. AIR supports either Flex development, or HTML applications which run in WebKit. The ugly side of this flexibility is that there are two SDKs, even two JavaScript virtual machines with different capabilities and characteristics. While it is nice to have a way to render HTML, I am not convinced that the web application model is worth it, given the complications it causes. After all, web applications run perfectly well in the browser.
  • Lack of UI standards may lead to annoying inconsistencies between AIR applications. We are used to this on the Web; now it is coming to the desktop as well.
Sandra Earl

YUI Theater - Doug Geoffray: "From the Mouth of a Screenreader" » Yahoo! User... - 0 views

yuiblog.com/...video-geoffray

accessibility screen reader general multimedia FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • he context is important for us on the frontend as we begin to confront the same challenges that desktop software developers have been addressing for many years.
  • Doug been a touchstone for us at YUI in the research and development of our Menu Control, a project that is helping us to lay a foundation for what is possible in terms of DHTML accessibility as YUI evolves.
cecilia marie

My Computer Problem Was Solved in a Few Minutes - 1 views

I had a good internet connection for the past few weeks. Then I began to observe that it was not working the way it should be compared to the past few weeks. I tried to troubleshoot it myself but, ...

computer problem online help fix

started by cecilia marie on 13 Oct 11 no follow-up yet
seth kutcher

Certified Expert Remote PC Tech Support Provider! - 1 views

I used to have a slow computer. It would take 10 minutes to boot up and then another 10 minutes to load. It was really a big headache. Good thing I called Remote PC Repair Now . Their remote PC...

remote PC repair

started by seth kutcher on 02 Nov 11 no follow-up yet
Vernon Fowler

Prettier Accessible Forms · An A List Apart Article - 0 views

alistapart.com/...prettyaccessibleforms

accessibility formdesign forms screenreaders

shared by Vernon Fowler on 09 Feb 19 - No Cached
  • The fieldset element allows us to group form controls into logical, related “chunks.” legend then allows us to add a caption to that fieldset, which helps users understand the context of the form controls contained within that fieldset. In some screen readers, the legend is associated with each form control within a fieldset and is read out after each tab of the keyboard, so that a particular control can always be referenced back to its legend.
  • Vernon Fowler on 09 Feb 19
     
    "The most important part of a form is the HTML we use to build it. Fortunately, HTML gives us a nice assortment of tags to build our forms in an accessible way. These are fieldset, legend, and label."
Vernon Fowler

WCAG 2.1 is Coming-and Here's What You Should Know Right Now - Siteimprove - 0 views

siteimprove.com/...what-you-should-know-right-now

forms usability buttons inclusivedesign errors navigation accessibility mobile touch

shared by Vernon Fowler on 09 Apr 18 - No Cached
  • Expect the new WCAG standards to emphasize a mobile experience that matches what users might expect from a traditional browsing session. This will likely include making your site’s touch screen functions more compatible with assistive technology. 
  • The new standards are expected to raise that level to 400% to help users with low vision navigate sites more smoothly.
  • WCAG 2.1 will likely seek to place limits on where and when pop-ups and similar advertising can appear. 
  • ...1 more annotation...
  • For users with motor skill issues, clicking on incorrect links and buttons is a common problem. WCAG 2.1 will likely require improvements in navigation technology that makes it easier both to find the right link and to correct actions if the wrong link is clicked. 
  • Vernon Fowler on 09 Apr 18
     
    Considering how massively the online landscape has changed in the past decade, it's amazing that international standards for web accessibility haven't been updated since December of 2008. That's about to change. After soliciting and assessing recommendations from the public, the international Web Accessibility Initiative is set to announce version 2.1 of its Web Content Accessibility Guidelines in the middle of this year. As that update draws nearer, there are a few key changes website owners may want to start planning for. (Keep in mind that all WCAG 2.1 changes are tentative.)
Vernon Fowler

WebAIM: Usable and Accessible Form Validation and Error Recovery - 0 views

webaim.org/...formvalidation

validation accessibility usability forms errors aria

shared by Vernon Fowler on 16 Mar 17 - No Cached
  • Errors on top
  • As one would guess, the "Errors on top" approach causes the error message to appear before the form. When presented, focus should generally be set directly to this error message. This allows screen reader and keyboard users to immediately access the error message without having to find it amongst the rest of the page contents. The message should also be visually apparent. Focus can be set to the message with client-side scripting using JavaScript focus() or similar, or the server-generated page can include an anchor name in the URI (e.g., http://myserver.com/form.php#errormessage) which will set focus directly to a named anchor or element id located at the beginning of the feedback message.
  • also helpful to inform the user as to the number of errors that were detected
  • ...2 more annotations...
  • provide a link within the error message that will set focus to the appropriate form control
  • Regardless of the mechanism used to identify and recover from form errors, aria-invalid="true" should generally be set on each invalid form control. This attribute causes screen readers to identify the control as being "invalid" or in need of attention.
‹ Previous 21 - 40 of 44 Next ›
Showing 20▼ items per page