91�ȱ�

These three principles embody an approach to the design and development of inclusive and usable applications and websites for all.

Use platform and web standards as intended

Always use web and platform specific standards as intended. When standards and guidelines are implemented using non-standard techniques there is a risk that users who are dependant on platform specific accessibility features such as accessibility settings and screen readers will be excluded.

Platform specific guidelines include the , the and the section of the Android guidelines. For the web there are the as well as the resources from W3C.

Use standard user interface controls where possible

Standard UI controls, objects, and elements should be used to ensure a greater level of accessibility. Custom controls tend to not implement accessibility as fully as standard platform controls. For example in iOS standard controls will have traits assigned that are understood by VoiceOver and therefore users.

Support platform accessibility

All content and functionality must work alongside, and not suppress, native accessibility, features and settings.

Navigation methods

All content must be accessible and navigable using the platforms navigation paradigm for assistive technology.

For example, the directional controller must be supported on Android to allow users of the TalkBack screen reader to review and navigate page content. Android requires that all elements be keyboard accessible so they can be accessed with a d-pad or track ball. Android 4.0 has lessened this requirement a bit by including an “Explore by Touch” method.

On iOS it is possible to hook items into the Accessibility API by ensuring all meaningful items have ‘accessibility enabled’ which in turn makes them focusable.

Support platform assistive technologies or features

When applications or sites block, disable, or interfere with platform specific accessibility features or technology, users with disabilities may not be able to use the site or app. Potential issues include suppressing zoom on websites or disabling the ability to highlight and copy text in HTML and therefore ‘Speak Text’ features.

Some users with disabilities may require multiple accessibility features because they have multiple disabilities. For example, a user may be deaf and blind or may have low vision and unable to use a pointing device or touch screen. Multiple modes of operation should be supported allowing users to access content according to their preferences.

On Android and iOS for example, built-in keyboard support should not prevent other standard touch events. iOS accessibility features and the API are designed to make accessibility information and input methods available to multiple disability types however some optimisation such as the deliberate misspelling of an accessibility label or hint to ensure correct pronunciation can make the content inaccessible to other disability types - for example, users of Braille who are deaf blind.