Archives for posts with tag: Android

I’ve always felt that making native apps accessible is slightly easier than websites partly because they’re more streamlined in terms of their UX but also because you’re only dealing with one programming language. If you’re looking for an easy place to start making your app accessible you can give it a boost by adding text alternatives for images, buttons and other meaningful UI elements.

Text alternatives have a dual benefit as they’re not only the hook that Talkback users need to understand your app but also the hook needed for automated testing  with tools such as Lint.  For this reason it’s not unusual to see apps where the alternatives are written for devs and testing purposes – such as ‘app_button’ rather than being human readable text alternatives such as ‘Submit’. This should be avoided; text alternatives are for users not testers.

To add text alternatives on Android use contentDescription:

<Button
    android:id=”@+id/submit_button”
    android:src=”@drawable/submit”
    android:contentDescription=”@string/submit”/>

For elements that change state such as an add/remove button use setContentDescription method to edit the alternative at runtime:

String contentDescription = "Select " + strValues[position];
label.setContentDescription(contentDescription);

For decorative images the contentDescription should be set to ‘null’:

android:contentDescription=”@null”

contentDescription should not be used for labelling form inputs – editText fields. The description is only read before the text field is populated by the user and lost altogether if the field is populated or cleared by the user. The next best option is to use the android:hint attribute. Like contentDescription, android:hint will be announced when the field is empty but ignored when the field is populated. Unlike contentDescription however it will be announced if the user clears the form input.

This is still not an ideal user experience and can be confusing for Talkback users who want to verify what form input is what when checking a form before it is submitted. A more robust technique is to use the LabelFor property which allows a visible label to be associated with an EditText box. This will be announced regardless of whether the input field is empty or populated with text. If a visible label is not possible (although I’d recommend against that) you can make the label invisible so it doesn’t change your visual layout.

Resources

 

Last June the Accessibility Team at BBC launched the BBC Mobile Accessibility Guidelines. You can find out more about the background of the guidelines in a previous post.

Over the last few months we have taken on board feedback, both internal and external, refined the requirements, revised some techniques and most importantly housed the guidelines in their own prototype HTML app. We wanted to take the standards and guidelines out of their dry Word format so they would be easier to read and use. There’s a lot of information in the document – it covers HTML, Android and iOS techniques after all – plus it has advice relevant to UX, development and editorial so we wanted to find a way to present the information so that it was a bit more targeted to you, your discipline and what issue you are wanting to address.

We’ve added an optional feature of offline storage so that you can access them whenever you want regardless of connection. You can  also search the standards and guidelines by topic (images, forms, structure, text alternatives etc), by discipline (UX, Development, Editorial) as well as focus on just HTML, Android or iOS techniques.

We’ll be tweaking the app, trying new things out, so do let us know if you have any comments either here of via the BBC blog post about the Mobile Accessibility Guidelines.

Download

You can grab a copy of the BBC Mobile Accessibility Guidelines v 1.0 from  the BBC Future Media Standards and Guidelines site.

Thank you

Big thank you to BBC who unfailingly support accessibility not just in terms of making products accessible but who also strive to make them fun, engaging and usable for people with disabilities. It’s an everlasting journey to try and get this right as technology changes but the BBC are by far the best organisation I have worked with when it comes to commitment.

There’s a small army of people who work hard on this within BBC but big thanks to Gareth Ford Williams who has supported and edited the guidelines and Ian Pouncey who has edited and helped pull together the site alongside IMI Mobile.

The BBC Mobile Accessibility Guidelines, otherwise known as ‘Are you missing a trick’, featured in .Net Magazine

Multiple ways of inputing and accessing information on the web is standard in accessibility but with the proliferation of mobile, tablets, touch, games consoles, kiosks (you name it) things are changing.

Where we were lucky if websites were designed with keyboard only users in mind it’s necessary to think beyond keyboard and mouse to include voice, movement, gestures, touch, switches, device motion, heartbeats (yes)…the list is, well, infinite. Not least because it will evolve and never end.

For me this is nothing new and something that accessibility has understood and been tackling for decades. With the proliferation of devices however there is now a convergence where access technology, with all its wonderful ways of providing means of input, is now converging with the mainstream. What we traditionally thought of as ‘assistive technology’ is now becoming something that many of us use dependent on context and device, or simply for fun, rather than solely by need.

Luke Wroblewski did a talk at dConstruct this year on Infinite Inputs discussing input types and how our interfaces have to adapt. He only mentions accessibility once (which is a good thing), but the whole piece covers inclusive design and innovation perfectly. Have a listen: Infinite Inputs.

Finally, after a long road of writing, editing, approving and everything else you can imagine I’m happy to say that a draft version of the BBC Mobile Accessibility Guidelines is finally published.

Continue Reading Draft BBC Mobile Accessibility Guidelines

Below are a handful of observations from user testing on mobile websites and applications I’ve seen recently. All users had some form of disability including people with limited mobility, sight impairments, cognitive impairments  dyslexia or hearing loss. Testing was carried out using Android or iOS with blind users accessing using the TalkBack or VoiceOver screen readers respectively. For obvious reasons I can’t share with you any details about the products.

Continue Reading User testing observations with disabled mobile users

If you have a disability, are a mobile user and have 5 minutes to spare please take a moment to fill out this online survey on mobile accessibility hosted on the The Paciello Group (TPG) site.

The data gathered will be a useful insight into mobile usage and help us  inform mobile accessibility strategy and development.

Obviously the more people filling it in the better to please pass this on to any other mailing lists, blogs or lists you might feel appropriate.

Big thank you to TPG and Kevin Chao for kick starting this.

Update February 1st, 2013

The preliminary results are in and available on the TPG website. It looks like more analysis is to come but I’d say there are few surprises.

WordPress SEO