When developing web applications, choosing a UI component library is one of the earliest decisions your team has to make. Beyond reducing the amount of functionality your team has to maintain, UI component libraries shield developers from the complexities involved in designing user interactions that are accessible and behave correctly across browsers and devices.
As accessibility-minded developers working on accessibility-minded teams, we strive to design and build inclusive applications that yield a pleasant experience for all users. However, despite our best efforts we may make mistakes and implement features in a sub-optimal way, or worse, discover that some users cannot use those features at all.
The web is for everyone. That includes web apps built on web architecture. If you haven’t heard the word “accessibility” mentioned in the last couple of years, you may have been living under a rock. Building accessible, inclusive web apps that support users with disabilities is becoming standard protocol.
Ensuring that your app or site is designed with accessibility as a priority isn’t only good design—it also makes good business sense. Giving thought to this early on in the product creation can save you headaches by reducing design and technical debt for your team.
The 2018 edition of the Node+JS Interactive conference featured nearly 1,000 JavaScript and Node.js enthusiasts at the first combined event organized by the Node.js Foundation and JS Foundation. The event included nearly 100 sessions, panels, and community events designed to help grow and foster the JavaScript ecosystem.
We usually take for granted how efficiently maps convey information like proximity, spatial relations, distance, and geographical context in a compact visual manner across two dimensions. Attempting to translate that to a non-visual medium and navigate interactive elements linearly by keyboard quickly pulls back the curtain on that illusionary ease.
At the recent TSConf, SitePen engineer Sarah Higley delivered a talk titled Escape the Office: Designing Interfaces for Other Developers. The moment you step into any large project or open source venture you must accept that code you write gets used in ways you did not originally intend.
Picture lots and lots of dogs wearing vests Now, are you thinking of a Lewis Carroll-esque canine tea party, or a collection of service dogs? If the latter, you may be ready to attend the thankfully-abbreviated California State University: Northridge Assistive Technology Conference (hereafter referred to as CSUN or #CSUNATC18).
At the recent NEJSConf, SitePen engineer Sarah Higley delivered a talk titled Don’t forget your keys. People tend to assume everyone navigates the world in the same way they do: on two legs, responding to visual cues, hearing speech, reading emotion. For developers, this often means web accessibility comes as an afterthought, if at all.
We have somehow reached a point in time where the integration of life in digital and physical spaces has spawned scores of scholarly articles with titles like “The emerging online life of the digital native.” In a practical sense, it has become increasingly difficult to participate in society without using the internet in some form.
The motivation for Intern 4 is to make it easier to author tests with ES6+ features within tests, with or without transpilation. Want to skim? Here’s the Intern Roadmap which lists our high level status for each Intern release going forward.
Intern already has a wide array of capabilities and today we’re pleased to announce one more: accessibility testing. Thanks to a generous award from Mozilla Open Source Support we’ve created the intern-a11y plugin, which allows users to run accessibility tests on pages or components using Intern.