Accessibility is more than making sure images have alternate text. I work with engineers, product managers, and designers to understand how accessibility impacts the users, set realistic deadlines, and create the solutions to provide a delightful experience to all users, regardless of their physical, sensory, or cognitive ability.
It’s not uncommon for a web page to include multiple sets of lists. This is especially true for a web site that aggregates information. The Yahoo! Finance home page contains at least 12 lists.
Screen readers allow the user to navigate a page via lists and announce the number of items in each list. But what if we could make this navigation more relevant? This can be done via the aria-labelledby attribute.
I first wrote this post shortly after textinputlayout was introduced and there was a distinct lack of documentation. My original code example for setting the error was incorrect. Per Victor Tsaran:
There is no such attribute as android:setError. There is a method called setError in the View class that can set the error message dynamically. That method actually works with TalkBack.
I will be updating the code examples soon. For now, do not include the android:seterror line shown below. I’m leaving it right now for archival purposes.
Google has done an admirable job defining the Material Design style guide. They’ve also begun rolling out new APIs that make it much easier to implement the interaction designs within Android and HTML. However, there are still some gaps. This article looks at the popular Text Input for Android interaction. Please note: the code in this article is not fully documented and the best practice may change as the Google Accessibility team updates their documentation. Consider this a beta pattern and I will gladly update it as we learn better practices. Continue Reading Accessible Android Inputs with Material Design
This article was originally written by Todd Kloots for the Yahoo! Accessibility Lab. It answers a very common problem for Mac computers and has been re-printed within the Intuit Accessibility blog with permission from Yahoo Accessibility.
Full keyboard access isn’t enabled by default in Mac OS. Often this leaves developers thinking there is something wrong with the implementation of keyboard access for a site or application, when in fact it is just a matter of changing a few system and browser preferences.
Android Studio, as well as IntelliJ Idea and Eclipse, provide a simple solution for testing your application for accessibility errors. This short video shows how to use the testing tool to find errors and fix an input that lacks a label.
I’ve met many small business owners with low vision that love using an iPad, or other tablet, as their key device. The iPad allows entrepreneurs to use a single device to handle all of their business tasks, such as point of sale, payroll, accounting, purchasing, and creating estimates on location. As a person with low vision, the built-in zooming functionality makes it easy to explore the screen and interact with the elements.
Karo Caran introduces how a person with low vision uses an iPad in this video
She recently created this new vidoe for a presentation on design for low-vision users. There are some key takeaways, such as consistency of banners and using background colors to differentiate between header, body, and footer.
Inheriting user preferences
While zooming is a great way to review content, not all low vision users want to use their applications in this manner. Many simply want to user the built in settings for higher contrast, bigger text, and reduced transparency to use their iPad without continually zooming in and out.
Your applications can automatically inherit these functions if you use standard iOS/Android components and the iOS Dynamic Type. If the app isn’t using Dynamic Type, we’ll need to check for a user’s display preferences and modify the fonts, colors, animation, etc.
The following code checks to see if a person has bold text enabled in their preferences. If so, use Avenir medium instead of light