Skip to main content

Home/ Web Accessibility/ Group items tagged screen reader

Rss Feed Group items tagged

Sandra Earl

WebAIM: Screen Reader Survey Results - 0 views

  • We received 1121 valid responses to the screen reader survey, which was conducted Dec. 2008 - Jan. 2009.
  • 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.
  • 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%
  • Skip to content22% Skip to main content28%
  • 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

untitled - 0 views

  • The upsurge in VoiceOver could be explained in part by iPhone now providing VoiceOver support; all of a sudden there is a very real reason to switch to Mac if you can use a screen reader you are familiar with on both your desktop and mobile.
  • The upsurge in VoiceOver could be explained in part by iPhone now providing VoiceOver support; all of a sudden there is a very real reason to switch to Mac if you can use a screen reader you are familiar with on both your desktop and mobile.
  • It’s good to also see the free, open source NVDA on the up. They’ve worked hard to include WAI-ARIA support and are becoming a key tool for web developers when testing.
  • ...4 more annotations...
  • We’re still faced with one massive problem with mobile access however and that’s the lack of an open, cross platform accessibility API that mobile screen readers can hook into. On desktop we have IAccessible2, MSAA and UI Automation (amongst others) but on mobile users are tied into one platform often only supporting one browser (such as iPhone, Blackberry RIM and others) so while desktop has opened up we find ourselves in a 1990’s type impasse with users left with little room to choose on mobile. Opera works well with VoiceOver but we have no way of telling if it works on the iPhone as it’s not supported. My hope is that with more users there’ll be more momentum behind breaking this stand off and opening up the market and ultimately giving users not only choice but portability between platforms.
  • It’s good to also see the free, open source NVDA on the up. They’ve worked hard to include WAI-ARIA support and are becoming a key tool for web developers when testing.
  • « Yay factor! Going global with standards and BBC Click on web accessibility Make video accessible, localised, mobile and searchable by captioning » Screen reader software usage shifts on desktop and mobile Nov 4th, 2009 by iheni WebAim released their 2009 Screen Reader Survey last week, a follow up from last years Screen Reader survey. Very good reading it makes too but of particular interest are results around screen reader choice on the desktop and increased screen reader access on mobile. For years it’s felt like screen reader users have mainly used IE on the desktop in combination with the major screen readers Jaws by Freedom Scientific and WindowEyes by GW Micro. It’s not that other platforms don’t support screen readers (we have Orca on Linux, VoiceOver on Mac) it’s just that IE seems to have dominated. As such what types of content and web technologies users can and can’t access has very much been driven by what the three software vendors Microsoft, Freedom Scientific and GW Micro have supported. This has made access to the open web a bit lopsided cutting down on choice for the end user, competition and by extension innovation. SVG is an example of a web technology that has possibly suffered by not being supported by IE and in turn by Jaws and WindowEyes. What’s interesting to see in this year’s survey is that Jaws and WindowEyes – while still the most used – have some stiff competition at snapping at their heels from open source, free screen readers (NVDA and  SAToGo ) and VoiceOver which is available with Mac: JAWS 75.2% Window Eyes 23.5% VoiceOver 14.6% System Access or System Access To Go 22.3% NVDA 25.6% While this year’s stats show little shift for Jaws and WindowEyes usage overall there is a significant leap forward for NVDA (NonVisual Desktop Access) and VoiceOver: 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. The upsurge in VoiceOver could be explained in part by iPhone now providing VoiceOver support; all of a sudden there is a very real reason to switch to Mac if you can use a screen reader you are familiar with on both your desktop and mobile. This could also explain the increase of screen reader users on mobile reported this year with 53% of survey respondents with disabilities confirming they use a screen reader on a mobile device. This is up from 12% last year (although last year’s survey doesn’t distinguish disabled from non-disabled users). I wonder how much this is to do with the ‘iPhone Factor’ but also can’t help thinking that social networking has done for the mobile web what Kylie Minogue did for Agent Provocateur – everybody wants some. And for me at least 2009 feels like the year that we all sat up and paid attention to the potential of mobile for people with disabilities. We’re still faced with one massive problem with mobile access however and that’s the lack of an open, cross platform accessibility API that mobile screen readers can hook into. On desktop we have IAccessible2, MSAA and UI Automation (amongst others) but on mobile users are tied into one platform often only supporting one browser (such as iPhone, Blackberry RIM and others) so while desktop has opened up we find ourselves in a 1990’s type impasse with users left with little room to choose on mobile. Opera works well with VoiceOver but we have no way of telling if it works on the iPhone as it’s not supported. My hope is that with more users there’ll be more momentum behind breaking this stand off and opening up the market and ultimately giving users not only choice but portability between platforms.
  • We’re still faced with one massive problem with mobile access however and that’s the lack of an open, cross platform accessibility API that mobile screen readers can hook into.
  •  
    "We're still faced with one massive problem with mobile access however and that's the lack of an open, cross platform accessibility API that mobile screen readers can hook into."
Vernon Fowler

WebAIM: CSS in Action - Invisible Content Just for Screen Reader Users - 0 views

  • recommended styles for visually hiding content that will be read by a screen reader
  •  
    "There are occasional instances where content should be made available to screen reader users, but hidden from sighted users. In most cases, if content (particularly content that provides functionality or interactivity) is important enough to provide to screen reader users, it should probably be made available to all users. Cases where verbose cues or instructions are provided only for screen reader users are most likely a reflection of poor design and accessibility. However, there are a few cases where information is apparent visually, but may not be apparent to screen reader users. In these cases, it may be appropriate to mark-up content in a way that it is read by a screen reader, but invisible to sighted users. "
Sandra Earl

Digital Web Magazine - Understanding Disabilities when Designing a Website - 0 views

  • In the UK In the US 2m people have a vision impairment3 10m people have a vision impairment4 8.2m people have mild to moderate deafness5, 688,000 people have severe to profound deafness6 28m people have a hearing impairment7 3.4m people have a physical disability8 8m people have a physical disability9 1.5m people have a learning disability10 6.8m people have a learning disability11 6m people have dyslexia12 25m people have dyslexia13
  • Most people who are blind will rely on screen reading software such as
  • JAWS or Windows-Eyes
  • ...41 more annotations...
  • refreshable Braille device which converts the text on the website into Braille.
  • Place form instructions before the form field
  • To improve accessibility and usability for screen reader users, form field requirements must be placed before the form field itself.
  • Provide a ‘skip to main content’ link Screen reader users benefit from a ‘skip to main content’ link as it enables them to jump over lengthy navigation to the main content of the web page, reducing the amount of content they have to listen to.
  • Ensure link text is descriptive Screen reader users using software such as JAWS can listen to the links on a web page through functionality known as a links list. If link text is not descriptive—solely using phrases such as “click here” or “more information”, for example—there is no way for screen reader users to determine where the link will take them.
  • Provide descriptive web page titles The first piece of information a screen reader user will listen to when they open a web page is the <title> assigned to the page. It is important, therefore, to use a title which reflects the content of the web page.
  • Provide descriptive headings It is important to provide descriptive headings
  • Screen reader users often listen to headings out of context from the main content
  • Provide audio descriptions and transcripts of video content Screen reader users depend on audio descriptions to provide additional information about important visual content displayed within a video.
  • Transcripts are written accounts of the video or audio content and can include additional information such as comments and descriptions
  • screen reader users cannot use a mouse
  • People with low vision will tend to use magnification software to make reading a website easier. Depending on the severity of their vision impairment, these users may combine magnification and screen reading software by using software products such as Supernova or ZoomText. For milder vision impairments, users may just increase the default size of text within their browser settings or change the colors to make the content more comfortable to read.
  • Avoid using images of text
  • Ensure text can be resized
  • Place key information in specific locations of the screen
  • ebsite search functionality is often located in the top-right corner of the web page
  • Juicy Studio color contrast analyzer.
  • it is possible to determine whether the colors chosen meet the minimum requirements specified in the WCAG Guidelines.
  • People with a hearing impairment tend not to use assistive software to improve their web browsing experience. Instead, they rely on the website being accessible by providing any audio content in alternative formats, such as captioning or transcripts.
  • By making audio content accessible for users with a hearing impairment, it also makes the content accessible for other users who find themselves in an environment where audio cannot be heard.
  • library with the sound turned down; they may be in a noisy environment where it is difficult to hear the audio; or they may be using a computer without speakers.
  • Provide captions for any video content
  • Provide transcripts of the spoken audio Where content is spoken without video, such as in a podcast, it is important to provide a transcript. It is recommended that the transcript be provided in plain accessible HTML to allow access by the widest possible audience, as opposed to a Microsoft Word or Adobe PDF document.
  • Physical disabilities range in severity from those who are temporarily disabled, for example having a broken arm, to those who are quadriplegic and have no use of any limbs. Depending on the severity of the physical disability, these users may access websites through voice recognition software such as Dragon Naturally Speaking.
  • However, what all users with a physical disability have in common is limited or no ability to use a mouse. This means that content within the website that requires a mouse click or fine motor control cannot be accessed by these users.
  • Ensure all content can be accessed via the keyboard
  • Users with a physical disability will have limited or no ability to use a mouse and as such will navigate websites using the keyboard.
  • Provide a focus state for links
  • Provide visible skip links Skip links are links that become visible when they receive focus, and are helpful for users with a physical disability. Keyboard users must tab through the web page to reach the particular link they are interested in—skip links allow lengthy navigation to be bypassed and reduce the number of key presses required to activate links in the main content.
  • Avoid moving targets Avoid using moving targets such as tickers, as users with a physical disability can find them very difficult to use.
  • Provide large clickable areas
  • provide sufficient whitespace between links
  • People with a cognitive or learning disability may have difficulties with memory, problem solving, perception, and conceptualization. In addition, people with a learning disability may have issues with reading and comprehension such as dyslexia.
  • To enhance the usability of the website for these users it is important that content is written in plain English, page layouts are simple in design, navigation is clear and consistent and there is no moving content to impede comprehension.
  • Provide the same look and feel throughout all pages of the website. Ensure that the navigation and main content are located in the same area of every page. Additionally, consider color coding different sections within the website. Users with cognitive or learning disabilities tend to find it easier to navigate around sections which are color coded.
  • Provide a site map A site map will enable users with a cognitive or learning disability to have a clear idea of the breadth of content contained within the website. The site map also enables users to directly access any page on the website, and helps if the user becomes lost.
  • Use a resizable sans-serif font which is left-aligned To increase readability for users with a cognitive or learning disability, use a sans-serif font which can be resized. Additionally, left-align content—justified text is more difficult to read due to the uneven spacing between words. Italicized and capitalized text should also be kept to a minimum to aid readability.
  • Provide helpful error messages
  • Offer speech output Organizations such as Browse Aloud and Textic enable content from a website to be spoken when highlighting the words on a web page. Offering this functionality is especially helpful for users who find it difficult to read large amounts of text.
  • Provide an Easy Read Version Consider providing an ‘easy read’ version of complex content. This combines plain text with images to aid understanding of the information. For an example of an easy read document see the Department of Health’s Making Lives Better for People with a Learning Disability.
  • Provide different color schemes People with cognitive or learning disabilities may benefit from different color scheme options. It is helpful if an easy read scheme such as a lemon background with dark text, and a hi-viz scheme such as a black background with yellow text, are provided.
Sandra Earl

Introduction to screen readers and screen magnifiers | 456 Berea Street - 0 views

  • And that leads me to three great videos posted on the Yahoo! User Interface Blog: In Introduction to Screen Readers, Yahoo! engineer Victor Tsaran talks about who will be likely to use a screen reader, how screen readers work, and how they can be used to interact with the computer desktop and to browse web sites. In Introduction to Screen Magnifiers, Karo Caran shows how the screen magnifier ZoomText is used to make the computer desktop and web sites readable to people with reduced vision. And finally, in From the Mouth of a Screenreader, Doug Geoffray from GW Micro (Window-Eyes vendor) talks about the history of screen reading software and how they analyse what is displayed on the screen in order to speak it to the user.
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
Sandra Earl

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

  • 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

Turn Firefox into a screen reader with Fire Vox | 456 Berea Street - 0 views

  • For anyone who hasn’t heard of Fire Vox, it is a free, open source screen reader extension for Firefox that works on Windows, Mac OS X, and Linux. Among other things it has support for WAI-ARIA and the CSS3 Speech Module, and is a good alternative to VoiceOver if you’re on a Mac and need a screen reader for web browsing (or testing).
  • For developers Fire Vox makes it easy to check how their sites work in a screen reader. Sure, it’s just one of several available screen readers, but this one is free and cross-platform. In other words there is no reason for you not to have it installed, so grab a copy right now.
Vernon Fowler

Understanding screen reader interaction modes - Tink - 0 views

  • the screen reader intercepts most keypresses before they reach the browser, triggering an interaction with the virtual document instead
  • up/down keys move focus to the previous/next line instead of scrolling the page
  • space key to select a checkbox
  • ...3 more annotations...
  • enter key is used to activate a link
  • Not all keypresses are captured by the screen reader however. When the tab key is pressed it is automatically passed through to the browser where it causes keyboard focus to move to the next piece of interactive content
  • Although this mode switching may seem unintuitive to someone unused to Windows screen readers, it works well in practice and most screen reader users are unaware of what’s happening “under the hood”.
Vernon Fowler

WebAIM: Creating Accessible Forms - Screen Reader Form Accessibility - 0 views

  • This can be solved by associating form labels to form items on the page. The label should almost always be located adjacent to the form item itself. When a screen reader accesses a form item that has a <label> element associated with it, it will read the text within the <label> element and indicate the type of form item it is (e.g., "First Name. Text box" or "Age. Check box"). Labels are needed for all form elements, except for buttons; the screen reader reads the text that is on the button (e.g., "Submit button").
  • Let's hear what the form sounds like to a screen reader:
  • Let's hear what the form sounds like now, with the improvements that we made:
Sandra Earl

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

  • 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.
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.
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

Validation messages - 0 views

  • If there are any validation messages, the focus is set to the first invalid input: this way, a screen reader will immediately announce the associated message, so the user knows that there is at least one invalid input to be fixed.
  • For multiple radio buttons or checkboxes, the message is associated to the surrounding <fieldset>.
  • In addition to this, each invalid input is associated to its message using aria-describedby. This is important, as it makes sure that screen readers also announce the messages when navigating through the inputs using the Tab key.
  •  
    "Data submitted in a form is usually validated in some way. And if there is any unacceptable data, the form is traditionally re-displayed, together with validation messages. In such a case, it is important to immediately inform screen reader users, so they know that they have to look at their data and submit again. "
Vernon Fowler

NV Access - 0 views

  •  
    "NVDA (NonVisual Desktop Access) is a free "screen reader" which enables blind and vision impaired people to use computers. It reads the text on the screen in a computerised voice. You can control what is read to you by moving the cursor to the relevant area of text with a mouse or the arrows on your keyboard."
Vernon Fowler

Creating an Accessible Infographic | Access Matters Blog - 0 views

  • 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

Blind Access Journal: Window-Eyes 7.0: Releasing the Potential for Momentous Steps Forw... - 0 views

  • A screen reader simply enables a blind person to use the applications and operating system on a computer without sight by converting on-screen text into a Braille or spoken format. Intelligent screen readers like Window-Eyes deliver information in a linear format, interpret the active window, read complex web pages and perform many other advanced functions.
  • Although scripting is, by far, the number one enhancement found in this latest Window-Eyes release, other new features are noteworthy in their own right. Geoffray tells us that Window-Eyes is now 100 percent Unicode compliant. This enables access to foreign language text, certain PDF documents not previously readable, Microsoft Word’s smart quoting feature and any other situation where use of special symbols is required. Intelligent place markers may now be defined on dynamic web pages delivering quick access to a specific area of the page based not only on its virtual line number, but also on the text at the cursor. A new Eloquence speech synthesizer, access to the Firefox 3.0 web browser, support for the public beta version of Internet Explorer 8.0
Vernon Fowler

Places It's Tempting To Use Display: None; But Don't | CSS-Tricks - 0 views

  • I recently heard a heartbreaking story about a blind girl trying to apply for college and the form had missing labels so she had no idea what to put in what fields.
  • @media queries Turning on Voice Over in OS X and using Safari is a screen reader. Now imagine that Safari window was open to a very narrow width and the page had some @media queries for handling smaller viewports. And say that @media query hides some things with display: none in order to better visually accomodate the space. This could be good or bad for accessibility. Are you hiding a bunch of crap that isn't important to the page? Or are you hiding useful things that a person using a screen reader should have access to like they normally would.
Vernon Fowler

Image ALT Tag Tips for HTML | AccessAbility - 0 views

  • Alt text with acronyms should be written with spaces in between letters. For instance, <alt="I T S at P S U" > (read by a screen reader as "ITS at PSU")
  • While there is no official length restriction on the length of alt text, many experts recommend 125 characters or fewer because of restrictions within the JAWS screen reader.
  • LONGDESC has incomplete support among both visual browsers and screen readers, and is deprecated in HTML5.
Sandra Earl

Web Axe - Practical Web Design Accessibility Tips - Podcast and Blog: Fieldsets, Legend... - 0 views

  • Some tips from the article include:Fieldset and Legend tags must be used together, never independently of each other.Keep the content of the Legend tag brief (the Legend may be read when each of the controls contained in a Fieldset receive focus.)In Windows Eyes, the option to read the Legend tag is off by default.Fieldsets may be nested.
1 - 20 of 62 Next › Last »
Showing 20 items per page