Content tagged “accessibility”

  1. A11Y Style Guide

    The A11Y style guide comes with pre-populated accessible components that include helpful links to related tools, articles, and WCAG guidelines to make your site more inclusive. These components also serve as a guide for both HTML markup and SCSS/CSS code, to inform designers, front-end and back-end developers at every stage of the website’s creation.

  2. Accessibility for Teams

    Put together by 18F’s Accessibility Guild, Accessibility for Teams is…

    A “quick-start” guide for embedding accessibility and inclusive design practices into your team’s workflow.

    In the post announcing the website’s launch, Maya Benari notes:

    Accessibility is a crucial part of government product design. First, it’s the law. Federal agencies face legal consequences when they don’t meet accessibility requirements. Second, it affects us all. Whether you have a motor disability, you sprained your wrist playing dodgeball, you need a building to have a ramp for your wheelchair or stroller, or you literally just have your hands full, we all find ourselves unable to do certain things at different points in our lives. Accessible products are better products for everyone.

    Congratulations to Maya and everyone else on the team for launching this useful accessibility guide!

  3. Software development 450 words per minute - Vincit

    “Something’s a little bit off here.” That’s what I predict your first thought to be upon seeing my cubicle for the first time. There’s no screen or mouse in sight. Instead there’s a guy hammering away on a keyboard, staring at seemingly nothing.

    It’s only me, and my colleagues can assure you that I’m mostly harmless. I’m a software developer working at Vincit offices in Tampere. I’m also blind. In this blog post I’m going to shed some light on the way I work.

    Tuukka Ojala shares his experience and the tools he uses to develop software.

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

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

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

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

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

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

  10. 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?