A principle approach to design thinking and development
These principles embody an approach to the design and development of inclusive and usable applications and websites for all.
Based on lots of research with real users around the globe for more than three decades we can quietly assume clear principles have been formed. With these principles in hand you'll be able to deliver a quality to the highest standards so everyone can enjoy the true freedom and independance of the internet.
With the principles in hand guidelines and success criteria have been formed. Guidelines on the scale of the well known companies with their own expertice, innovations and differentiation but also from a neutral position in the form of a member consortium, the W3C who is setting the global standards.
Inclusive Design, or Universal Design, is for those who want to make great products for the greatest number of people
The question is not who is included but Who might get excluded and how to fix this?
Empathizing with users: A good designer gets married to the users’ problems. A bad designer gets married to his own solutions.
Inclusive Design Vs. Accessibility
A design methodology that enables and draws on the full range of human diversity.
- The qualities that make an experience open to all.
- A professional discipline aimed at achieving No. 1.
Use platform and web standards / specifications 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 from accessing the content.
Platform specific guidelines include the iOS Accessibility Guidelines, the Android User Interface Guidelines and the Designing for Accessibility portion of the Android guidelines and Material Design Accessibility
User Interface Controls
Use standard user interface components where possible
Standard User Interface Components (UIC), 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.
All UI controls provided by platforms have semantics build in and are very robust. They have been developed and tuned over a long period of time to work well with user agents like browsers and assistive technology. Semantics in this case are the characteristics to recognize components. Think of giving it a name, role and a value if needed.
For example in iOS standard controls will have traits assigned that are understood by the build in screen reader VoiceOver and therefore users. And for the web there are native HTML elements containing a role and when implemented according to the specifications get a proper name.
Support platform accessibility
All content and functionality must work alongside, and not suppress, native accessibility, features and settings.
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.