Content tagged “accessibility”

  1. WAI-ARIA Authoring Practices 1.1

    This document provides readers with an understanding of how to use WAI-ARIA 1.1 [WAI-ARIA] to create accessible rich internet applications. It describes considerations that might not be evident to most authors from the WAI-ARIA specification alone and recommends approaches to make widgets, navigation, and behaviors accessible using WAI-ARIA roles, states, and properties. This document is directed primarily to Web application developers, but the guidance is also useful for user agent and assistive technology developers.

  2. Removing Headaches from Focus Management | Google Developers

    An exciting accessibility change is coming to Chrome 50. Google calls it “focus starting point” and it’s a small—but incredibly helpful—change to how their Web browser manages focused elements and tab order.

    If something has focus, it’s also the focus navigation start point, just like before. Also, just like before, if nothing else has set the focus navigation start point, then it will be the current document or, if available and supported, the currently active dialog. If we navigate to a page fragment like in the example above, that will now set the focus start point. Also, if we click any element on the page, regardless of whether it is focusable, that will now set the focus navigation start point. Finally, if the element which was the focus start point is removed from the DOM, its parent becomes the focus start point. No more focus whack-a-mole!

    As the article explains, prior to this change, focus management can be difficult when tabbing around and moving within a document (or into and out of modal dialog boxes). Take heed of the note in the article’s caveats section:

    Sequential focus navigation starting point is currently only supported in Chrome 50, Firefox, and Opera. Until it is supported in all browsers you’ll still need to add tabindex="-1" (and remove the focus outline) to your named anchor targets.

  3. Answers to Questions About Performance — Google Developers — Medium

    Google’s Paul Lewis answers the same questions that Matt Gaunt received (and that I previously linked to). Paul’s focus on the user and their experience of our work resonates strongly with me and is something I harp on quite frequently.

    I think performance, accessibility, and security share some traits: they can’t be retro-fitted to a project, they’re often thankless tasks, and they’re only notable by their absence. They’re all, however, the bedrock of a good user experience, onto which you can layer high quality designs and interactions.

    Paul also cites one of my favorite documents, the W3C’s HTML Design Principles:

    In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

    Truth.

  4. Notes on Using ARIA in HTML

    This document is a practical guide for developers on how to add accessibility information to HTML elements using the Accessible Rich Internet Applications specification [WAI-ARIA-1.1], which defines a way to make Web content and Web applications more accessible to people with disabilities. This document demonstrates how to use WAI-ARIA in [HTML51], which especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

  5. Fifteen Years of “A Dao of Web Design”

    This week marks the fifteenth anniversary of one of the seminal articles on Web design: John Allsopp’s, “A Dao of Web Design.”

    Published on .

  6. Better for Accessibility — Simply Accessible

    You may have heard that display:none is bad for accessibility and that you should use off-left positioning instead. It isn’t about using display: none; or off-left positioning. It isn’t just about screen reader users. It’s about making an interface work for everyone with efficient keyboard access for everyone that needs it—sighted or not.

  7. Accessible HTML5 Video with JavaScripted captions - Opera Developer Community

    It’s great that HTML5 allows us to embed video into web pages that can then be displayed directly by browsers, without having to rely on third-party plugins. The elephant in the corner regarding all video — whether it be HTML5 or proprietary — is accessibility. What are conscientious developers to do to provide textual alternatives for those who can’t access the contents of the video?