Skip to main content

Home/ Web Accessibility/ Group items tagged WAI

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Sandra Earl

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

www.headstar.com/eablive

accessibility elderly general WCAG 2.0

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

The Accessibility of WAI-ARIA · An A List Apart Article - 0 views

alistapart.com/...the-accessibility-of-wai-aria

accessibility forms html aria

shared by Vernon Fowler on 10 Feb 14 - No Cached
  • Pages semantically enriched through WAI-ARIA do not currently validate, but this drawback is acceptable: Common browsers do not mind the additional markup.
  • Some sites currently circumvent the validation problem by adding WAI-ARIA attributes to the source code via a script that is executed when the page loads.
  • in HTML5, WAI-ARIA validates
  • ...1 more annotation...
  • as long as older screen reader/browser combinations incapable of interpreting WAI-ARIA still constitute a significant part of the installed base, web designers who care for accessibility should use WAI-ARIA markup only to enrich their sites. They should not rely on it.
Sandra Earl

untitled - 0 views

www.iheni.com/e-shifts-on-desktop-and-mobile

mobile accessibility reading best practices standards

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

WebAIM: Accessibility of Rich Internet Applications - 0 views

webaim.org/aria

accessibility ARIA WebAIM

shared by Sandra Earl on 12 Oct 10 - Cached
  • WAI-ARIA (Accessible Rich Internet Applications or ARIA) is a W3C protocol for enhancing and supporting accessibility of scripted and dynamic content.
  • ARIA provides accessible interactive controls (such as tree menus, drag and drop, sliders, sort controls, etc.), content roles for identifying page structure (navigation, search, main content, etc.), areas that can be dynamically updated (called "live regions" in ARIA), better support for keyboard accessibility and interactivity, and much more.
  • WAI-ARIA provides the ability for developers to specify roles for document areas (and many other things).
  • ...2 more annotations...
  • accessibility issues with rich internet applications can be characterized as: Providing the semantic structure of page areas and functionality (e.g., navigation, main content, search, etc.) Maintaining accessibility of content that is dynamic and may change within the page (e.g., AJAX content updates) Allowing certain non-focusable page elements to receive keyboard focus (e.g., setting focus to an error message within the page) Providing keyboard and screen reader accessibility with complex widgets and navigation elements (e.g., sliders, menu trees, etc.)
  • ARIA is being implemented into many scripting libraries (such as jQuery, Dojo, YUI, and GWT). While developers can certainly implement ARIA into their advanced widgets and applications, using ARIA-supported libraries greatly simplifies the process of providing this level of accessibility.
Vernon Fowler

The Same, But Different: Breaking Down Accessibility, Universality, and Inclusion in De... - 0 views

theblog.adobe.com/-universality-inclusion-design

a11y inclusivedesign twitter accessibility universal design

shared by Vernon Fowler on 24 May 18 - No Cached
  • One way to put a name to this activity is to say that we are going up the mountain — in other words, moving upward is our goal. Another is to refer to reaching the summit — the destination to which we aspire. The former says, in effect, “We are gradually making our way up the hill.” The latter says, “We’re not done until we get to the top.”
  • Inclusive design is the practice of going up the mountain — we can always look for ways to include more people and situations to our designs, even if the result only gets us a few steps up the trail at a time.
  • I would go so far as to say that it’s the scope of that task — the seemingly infinite nature of including everyone — that is too big of a challenge. We aren’t all born to be mountain climbers. But together we can get a little farther up the hill, if we try.
  • Vernon Fowler on 24 May 18
     
    My post on the @adobe blog is up. It's about how I distinguish inclusive design from accessibility, and why you still need to go back and learn about universal design. https://t.co/OsjUp57F29 #a11y #inclusivedesign Great article on the nuances between A11y, Inclusive Design and Universal Design. Thanks @mattmay The Same, But Different: Breaking Down Accessibility, Universality, and Inclusion in Design https://t.co/QJIXT7y96T via @adobe
Vernon Fowler

Validation messages - 0 views

www.accessibility-developer-guide.com/...validation-messages

forms accessibility validation

shared by Vernon Fowler on 09 Feb 19 - No Cached
  • 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.
  • Vernon Fowler on 09 Feb 19
     
    "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. "
mesbah095

Guest Post Online - 0 views

guestpostonline.com

accessibility general standards development usability webdesign design resources reading FUSION09

shared by mesbah095 on 03 Apr 14 - No Cached
  • mesbah095 on 03 Apr 14
     
    Article Writing & Guestpost You Can Join this Site for Your Article & guest post, Just Easy way to join this site & total free Article site. This site article post to totally free Way. Guest Post & Article Post live to Life time only for Current & this time new User. http://guestpostonline.com
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

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

www.456bereastreet.com/..._a_screen_reader_with_fire_vox

accessibility screen reader Fire Vox

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

zomigi.com » Why browser zoom shouldn't kill flexible layouts - 0 views

zomigi.com/...shouldnt-kill-flexible-layouts

accessibility development design vision low vision zoom magnify

shared by Sandra Earl on 12 Oct 10 - Cached
  • Liquid layouts get rid of the dreaded horizontal scrollbar
  • Liquid layouts allow you to make full use of the area available in the viewport, showing more or less content, depending on what will fit at any given moment.
  • Liquid layouts essentially allow users to choose the line length, or number of text characters per line of text, that is most comfortable for them to read.
  • ...1 more annotation...
  • If you have images that you think the user will want to get a closer look at, you can choose to scale only these images using easy CSS tricks. You can set up your images and CSS in such a way that the images will have little distortion or blurriness when scaled dynamically by the browser. The other images can all remain a constant size, so that they don’t get in the way of users with very large text and contribute to horizontal scrollbars, float drops, or other nasty things that can happen when you put huge images into web pages. And of couse, if a user does want to scale one of the non-scalable images, they can always use the browser zoom function as a backup method.
Vernon Fowler

Universal Subtitles - Transcribe, caption, translate, and subtitle videos. - 0 views

www.universalsubtitles.org/en

MED104 subtitles accessibility education tools youtube transcription universal video vimeo

shared by Vernon Fowler on 01 Oct 11 - No Cached
  • Vernon Fowler on 01 Oct 11
     
    The easiest way to caption and translate any video. Subtitles make videos more powerful, more global, and more searchable.
Vernon Fowler

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

webaim.org/...invisiblecontent

accessibility hide content CSS

shared by Vernon Fowler on 27 Nov 13 - No Cached
  • recommended styles for visually hiding content that will be read by a screen reader
  • Vernon Fowler on 27 Nov 13
     
    "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. "
Vernon Fowler

5 Ways to Offer a Better UX for Disabled Users - 0 views

www.sitepoint.com/offer-better-ux-disabled-users

accessibility research empathy colour typography video captioning webdesign

shared by Vernon Fowler on 08 Mar 16 - No Cached
  • Vernon Fowler on 08 Mar 16
     
    Empathy is unrivalled as a skill a user interface designer should have. Walking in somebody else's shoes (or seeing through their eyes may be a better metaphor), can be a temporary replacement for having a user/tester at hand. Let's take a look at some disabilities that we so often forget.
Vernon Fowler

Don't Use The Placeholder Attribute - Smashing Magazine - 0 views

www.smashingmagazine.com/...placeholder-attribute

inclusive input formdesign aria forms inclusivedesign hint accessibility form html

shared by Vernon Fowler on 27 Jun 18 - No Cached
  • To recap, the placeholder attribute: Can’t be automatically translated; Is oftentimes used in place of a label, locking out assistive technology; Can hide important information when content is entered; Can be too light-colored to be legible; Has limited styling options; May look like pre-filled information and be skipped over.
  • Move the placeholder content above the input, but below the label:
  • Development Here’s how to translate our designed example to code:
  • ...4 more annotations...
  • aria-describedby ensures that the p content will be described last, after the label’s content and the kind of input it is associated with.
  • By using aria-describedby to programmatically associate the input with the p element, we are creating a priority of information for screen readers that has parity with what a person browsing without a screen reader would experience.
  • The floating label effect, a close cousin to this phenomenon, oftentimes utilizes the placeholder attribute in place of a label, as well.
  • Content hidden by an on-screen keyboard. 3rd party keyboards with larger heights may have a greater risk of blocking important content.
  • Vernon Fowler on 27 Jun 18
     
    Not only argues for not using the placeholder attribute but also describes an inclusive input hint and how to code it.
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

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

www.brucelawson.co.uk/...actical-value-of-semantic-html

accessibility html mobile navigation

shared by Vernon Fowler on 25 Feb 19 - No Cached
  • styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we’re able to ensure that the author, publication date, title, and subheading are prominently featured.
  • If you plan to put things into microdata, please note that Apple, being Apple, go their own way, and don’t use a schema.org vocabulary here. Le sigh. See my article Content needs a publication date! for more. Or view source on this page to see how I’m using microdata on this article.
  • Apple WatchOS also optimises display of items wrapped in <figure> elements
  • ...4 more annotations...
  • First, choose the appropriate type attribute and element tag for your form controls. WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.
  • unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.
  • By choosing the right semantics now, a machine that I don’t know about yet can understand my content and display it in the best way for its users.
  • Semantic HTML will give usability benefits to many users, help to future-proof your work, potentially boost your search engine results, and help people with disabilities use your site.
Vernon Fowler

Don't Rely on Default Browser Error Messages - Intopia - 0 views

intopia.digital/...default-browser-error-messages

accessibility forms validation HTML5

shared by Vernon Fowler on 06 Feb 19 - No Cached
  • Another issue is that the messages are temporary. As soon as you put focus on the input with mouse, keyboard or touch, the message disappears. People with cognitive impairments will find it difficult to use these, and I think anyone trying to fill in the form while they’re distracted will have trouble as well. People who rely on the keyboard for navigation (which includes both sighted users and screen reader users) will also lose these messages as they move around the form.
  • If you’re confident of your error messages, you can remove the browser validation by adding the novalidate attribute to the wrapping form element, like this: <form novalidate>...</form>
  • You can style this with CSS, using the :valid and :invalid pseudo-classes
  • ...2 more annotations...
  • Only the first error is noted with a message.
  • The rest rely on a change of border colour, which is, again, not evident to screen reader users.
  • Vernon Fowler on 06 Feb 19
     
    "When I found out the major browsers were beginning to include error validation into their support for forms, I was pretty excited. Form validation is always a fiddly part of accessibility, so I'm always looking out for ways to make it easier for developers to do properly. I read MDN's form data validation tutorial and a CSS Tricks article on client-side form validation and immediately made some test forms. Sadly, I was disappointed with the results. The default error validation in browsers is almost completely inaccessible. I was hoping we'd get default "you've forgotten to fill this in" messages that could be customised. I might have been a bit too optimistic! Validation at the browser level has many of the same issues we find at the website level."
Vernon Fowler

HTML5 Accessibility Chops: When to use an ARIA role | The Paciello Group Blog - 0 views

www.paciellogroup.com/...chops-when-to-use-an-aria-role

accessibility html5 browser

shared by Vernon Fowler on 24 Nov 12 - No Cached
  • The situation for new HTML5 elements is different and likely to remain so for some time. It will be years before New HTML5 elements get robust accessibility support implemented across browsers and platforms. This is particularly so for non interactive elements such as the new HTML5 structural elements because  accessibility APIs in general do not have defined roles for many non interactive elements. In this case it is recommended to add the appropriate ARIA roles to elements that are meant to convey meaning but are effectively meaningless due to lack of implemented accessibility support. For example, adding role=navigation to a nav element fills the gaps in support for HTML5 semantics as ARIA  is more robustly  supported by most modern browsers and assistive technology:
  • <nav role=”navigation”>
  • Authors/developers can safely assume that any element that has been around since HTML 4.0 is already accessibility supported in browsers that support accessibility. So they do not need a default implicit role added.
1 - 20 of 49 Next › Last »
Showing 20▼ items per page