Skip to main content

Home/ Web Accessibility/ Group items tagged accessibility

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Sandra Earl

How did you get into Web accessibility? | 456 Berea Street - 0 views

www.456bereastreet.com/...you_get_into_web_accessibility

accessibility reflection testimonial

shared by Sandra Earl on 12 Oct 10 - Cached
  • Personally I have several reasons for advocating Web accessibility. First of all an idealistic one: I want everybody to be able to use the Web. I am not disabled (yet), so I can (and am often forced to) muddle through sites that are badly built, but a person with a disability may not be able to. Since it is possible to build sites that almost everybody can use, I don’t see why we shouldn’t. Then a few reasons that some may call selfish: I do not have any problems related to motor skills, but I have a really hard time using dropdown and flyout menus, especially hierarchical ones, as well as phony Flash or JavaScript scrollbar imitations. Accessible sites in general either do not contain such obstacles or provide ways around them. Despite having no substantial eyesight problems, I find reading tiny text (below 11px is tiny to me), low contrast text, and reading any size high contrast, light-on-dark text to be very straining. A website designed with accessibility in mind is less likely to cause legibility problems for me. I like being able to use my keyboard to navigate websites. Accessible sites are keyboard friendly since they do not force people to use a mouse.
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

Web 2.0: Understanding Web Accessibility - 0 views

infosysblogs.com/...standing_web_accessibilit.html

accessibility general FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • As stated by renowned accessibility expert Shawn Lawton Hewitt, Web Accessibility simply means that people with disabilities can use the Web.  More specifically, Web Accessibility means that people with disabilities can perceive, understand, navigate and interact with the Web.
  • It is important to understand one aspect that most experts agree on – an individual web site can never be perfectly accessible to everybody. This has to do with the sheer diversity of disabilities as well as the potential overlap of multiple disabilities. But a systematic approach like implementing the WCAG guidelines can go long way in accommodating a very large number of people.
Vernon Fowler

Responsive Design is Too Responsive? - 0 views

www.visionaustralia.org/...sive-design-is-too-responsive-

design responsive design responsive webdesign accessibility css3 media queries mediaqueries

shared by Vernon Fowler on 07 Apr 13 - No Cached
  • When you use browser zoom in Webkit browsers (Chrome and Safari), all elements on the page increase in size and start overlapping content. This is because WebKit browsers zoom to make the content bigger but the width of the browser remains unaffected, which means it doesn’t trigger responsive style sheet elements or address layout issues.
  • This is an accessibility issue as users with vision deficiencies use browser zoom to navigate websites. If they use Google Chrome they will have a lot of issues accessing content.
Vernon Fowler

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

www.alistapart.com/...now-you-see-me

css webdesign accessibility usability content javascript class

shared by Vernon Fowler on 28 Oct 12 - No Cached
  • 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
      Vernon Fowler on 17 Mar 13
       
      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

Inclusive Design: Accessible user experiences on the web « UX Australia 2010 - 0 views

www.uxaustralia.com.au/...inclusive-design

inclusive accessibility accessible user experience webdesign WCAG Design userResearch research workshop UX web

shared by Vernon Fowler on 07 Apr 17 - No Cached
  • Understanding how to incorporate accessible design practices within a project
  • Integrating accessible, inclusive design practices throughout traditional UX research and design practices
Vernon Fowler

Customizing the Read More « WordPress Codex - 0 views

codex.wordpress.org/Customizing_the_Read_More

WEB300 wordpress accessibility links

shared by Vernon Fowler on 12 Apr 17 - No Cached
  • To customize this text, add the following code to your functions.php file.
  • If you are using a Child Theme, the above code will not work without modification if the parent theme has its own filters setting its own "more" link.
  • The following code is an example of the additional code needed to get the above code to work from a child theme of the parent theme Twenty Eleven. You will need to examine your actual parent theme's code for the correct parameters in the remove_filter() code, they must exactly match the add_filter() parameters used by the parent.
  • ...1 more annotation...
  • If you want to include the title of the post in the more text, use the_title() template tag
    • Vernon Fowler
      Vernon Fowler on 12 Apr 17
       
      Already done for you in accessibility-ready themes like twentyseventeen. If unsure, check by either looking for a screen-reader-text span inside the "Continue reading" link; or install the WP Accessibility plugin to confirm under Miscellaneous Accessibility Settings. https://wordpress.org/plugins/wp-accessibility/
  • Vernon Fowler on 12 Apr 17
     
    "Modify the Read More text when using the the_excerpt()"
Vernon Fowler

HTML_CodeSniffer - 0 views

squizlabs.github.io/HTML_CodeSniffer

accessibility bookmarklet tools html WCAG wcag2

shared by Vernon Fowler on 16 Feb 14 - No Cached
  • Vernon Fowler on 16 Feb 14
     
    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

Thoughts around universal access on mobile from Accessibility 2.0 » iheni :: ... - 0 views

www.iheni.com/ess-on-mobile-accessibility-20

mobile accessibility design best practices

shared by Sandra Earl on 12 Oct 10 - Cached
  • Yahoo’s! graded browser support helps developers framework what browsers and versions they should target on desktop. This got me wondering if we need something similar for mobile. Seeing as Chris Heilmann from Yahoo! was sat in the audience I thought I might direct the question at him during the panel (also mentioned over Twitter) and being the thoroughly top bloke he is he listened. I know many larger orgnisations will have this sot of information fed into the test plans but for the large majority of us we have to figure it out as we go along. Not only that it’s such a fast changing target that it’s impossible to keep up with on your own.
  • Sandra Earl on 12 Oct 10
     
    "Yahoo's! graded browser support helps developers framework what browsers and versions they should target on desktop. This got me wondering if we need something similar for mobile. Seeing as Chris Heilmann from Yahoo! was sat in the audience I thought I might direct the question at him during the panel (also mentioned over Twitter) and being the thoroughly top bloke he is he listened. I know many larger orgnisations will have this sot of information fed into the test plans but for the large majority of us we have to figure it out as we go along. Not only that it's such a fast changing target that it's impossible to keep up with on your own."
Sandra Earl

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

www.456bereastreet.com/...of_websites_still_inaccessible

accessibility laws statistics general standards testing

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

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

webaim.org/ajax

accessibility AJAX ARIA WebAIM

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

How do you figure? | scottohara.me - 0 views

www.scottohara.me/...how-do-you-figure.html

HTML5 markup accessibility screenreaders

shared by Vernon Fowler on 30 Jan 19 - No Cached
  • Vernon Fowler on 30 Jan 19
     
    A figure can be used with or without a figcaption. However, without a caption, or an alternate means of providing an accessible name (e.g. aria-label) a figure may not provide much value in conveying its semantics alone. In some cases, it may not convey any semantics at all if its given no accessible name.
Vernon Fowler

Data show small improvements in accessibility of course materials - 0 views

www.insidehighered.com/...accessibility-course-materials

accessibility culture change

shared by Vernon Fowler on 10 Jun 17 - No Cached
  • Vernon Fowler on 10 Jun 17
     
    But new data from Blackboard show that the most common types of course content that students use on a daily basis -- images, PDFs, presentations and other documents -- continue to be riddled with accessibility issues. And while colleges have made some slight improvements over the last five years, the issues are widespread.
Vernon Fowler

Accessible Breadcrumb Navigation - 0 views

scottaohara.github.io/a11y_breadcrumbs

navigation accessible accessibility markup

shared by Vernon Fowler on 17 Jul 19 - No Cached
  • Being that a breadcrumb is contained within a nav element, it will be surfaced as a landmark to screen readers. Providing it an accessible name of "breadcrumb" (or whatever term may be more meaningful to your site) will help differentiate it from any other navigation landmarks in the current document, such as the primary navigation
  • using aria-label to provide an accessible name, and aria-current to indicate the currently active link
  • screen reader support for aria-current is rather good
  • ...2 more annotations...
  • Some other breadcrumb patterns remove the <a> element, or at least the href from the link. These examples retain the a href for current link, as without it, people using a screen reader and navigating by links, or via focusable content with the tab key would not come across the currently active link.
  • Breadcrumbs are useful on large websites where pages have clearly defined hierarchy.
‹ Previous 21 - 40 of 448 Next › Last »
Showing 20▼ items per page