diff --git a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/AccessibilityFeatures/AccessibilityFeatures.md b/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/AccessibilityFeatures/AccessibilityFeatures.md index ef340bc..3eaede9 100644 --- a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/AccessibilityFeatures/AccessibilityFeatures.md +++ b/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/AccessibilityFeatures/AccessibilityFeatures.md @@ -1,6 +1,6 @@ # Accessibility Features -A brief overview of **assistive technology** supported by iOS +In-built software **assistive technology** of iOS @Metadata { @PageColor(blue) @@ -19,7 +19,48 @@ A brief overview of **assistive technology** supported by iOS label: "General Knowledge") } -**Accessibility Features** is a collection of *software* aimed to **help people use their devices**. +**Accessibility Features** are specialised system software purposed to customise user experience of Apple devices. + +Every person has a unique set of sensory, physical and cognitive features. There are people that encounter certain barriers while using information and communication technology (ICT). + +It is impossible to consider the whole diversity of users, which would be designing specifically for each member of world population. + +Nonetheless, there are practices that are aimed to enable more people to access technology. When designing with accessibility in mind is not enough, assistive technology enter the game. + +Assistive technology are software, hardware and combined solutions. In this particular article, we are going to discuss Accessibility Features -- in-built system software purpose to customise user experience of Apple devices. + +Accessibility features let people adjust system settings that way so using a device becomes more comfortable or even simply possible for people in particular conditions. + +It may be achieved with means out-of-the-box or by letting a user extend the device's functionality by connecting external devices. + +Some accessibility features are fully autonomous and are supported automatically. Others require explicit consideration of developers. + +For example, classic Invert Colours perfectly works on its own, because this technology simply inverts every colour of the interface. + +On the other hand, there is Smart Invert that does the same but is considerate of images, videos and media with already sufficient colour scheme. Smart Invert will work as intended only if supported explicitly -- if everything that shouldn't be inverted is marked inside of the application. + +On this page we are going to discuss accessibility features from a distance. It is essential to understand what can be done to an interface in order to provide accessible experience. + +But there are accessibility features that require more of attention, because to enable them additional work has been done. Such features are discussed in greater detailed in next articles, one by one. + +But before diving deep into details, let's get familiar with accessibility features and their functionality in general. + + +## Speech +Speech accessibility features are aimed to adjust user experience for people in circumstances affecting their ability to speak. + +## Vision +Vision accessibility features work with the visual modality of an interface. + +## Hearing +Hearing accessibility feature are purposed to customise user experience for people with hearing disabilities. + +## Mobility + + +## Cognitive + +There are various features that adjust or extend the functionality of iPhone to enable different people have an equitable experience. You can find **Accessibility Features** available for your device in **Settings**, under **Accessibility** category. diff --git a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/AccessibilityInCode.md b/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/AccessibilityInCode/AccessibilityInCode.md similarity index 100% rename from Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/AccessibilityInCode.md rename to Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/AccessibilityInCode/AccessibilityInCode.md diff --git a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/Accessibility/a11yTerminology.md b/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Terminology/a11yTerminology.md similarity index 82% rename from Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/Accessibility/a11yTerminology.md rename to Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Terminology/a11yTerminology.md index 09f7f1f..6f306d7 100644 --- a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/Accessibility/a11yTerminology.md +++ b/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Terminology/a11yTerminology.md @@ -40,7 +40,7 @@ Every person has unique **capabilities** and **experience**. There are **conditi } Talking about barriers in **digital products**, they happen on the scope of **user interfaces**. A **user interface** is *everything* that happens between a **product** and its **user**, the *communication* between these two subjects. -### Computer interfaces +### Informational exchange User interfaces are essentially means of **informational exchange**: providing **input** and receiving **output**. ### Accessibility of user interfaces @@ -57,19 +57,26 @@ These are **principles of accessible design**. [**iOS Accessibility Handbook**]( We will study accessibility by these principles **in general** and inspect each of them in detail later at the [**Accessible Design**]() page. -> Note: Yes, there is **W** in WCAG, WAI and W3C, and we are talking **mobile**. +### -- W is for Web. We're talking Mobile. +That's right, excuse me. But the absence of widely-recognised standards for mobile accessibility should not be an obstacle on our way. + +Interface theory is shared between various technology, accessibility principles are widely applicable. We just have to make sure that we understand what we're doing to get it right. And that's why this handbook exist. ## Assistive technology -But there are situations where *design means* are **not enough** for an interface to be accessible. Here comes **assistive technology**: software, hardware and combined solutions that *allow* users to be able to have **equitable interaction experience**. +There are situations where *design means* are **not enough** for an interface to be accessible. Here comes **assistive technology**: software, hardware and combined solutions that *allow* users to be able to have **equitable interaction experience**. ### Equity vs. equality -Notice that the word *equitable* is used instead of *equal*. It is done because **demanding equal access is delusional**: there is **no equation between people**, everyone is **unique** and their experiences are too. +Notice that the word *equitable* is used instead of *equal*. It is done because **demanding equal outcome is delusional**. There is **no equality between people**, everyone is **unique**. Treating *different* people the *same* way won't lead to the same results. + +Equality ensures that everyone gets the same -- *equal* -- treatment. Equity treats everyone differently, in accordance with their diversity, to achieve similar -- *equitable* -- results. ### Users of assistive technology -Most commonly, assistive technology is used by people for whom **otherwise* user interfaces would be inaccessible**. +Most commonly, assistive technology is used by people for whom ***otherwise* user interfaces would be inaccessible**. ### -- ... most commonly? -Yep. **Assistive technology *are* for people with disabilities**. But there is no requirement to have a disability to use assistive technology. +Yep. **Assistive technology *are* for people with disabilities**. But there is no requirement to have a disability to use assistive technology. + +Many things used in everyday life of people who do not identify themselves as having a disabilities were *indeed designed* for people with disabilities. For example, ergonomic handles and speech recognition. Sometimes assistive technology **Users of assistive technology** is the term we're going to use when discussing appropriate **technical implementation**. @@ -98,8 +105,8 @@ Type | Definition | Examples ---|---|--- **visual** | **Visual perception** impairments | *Blindness*, *low sight*, *colour blindness* **hearing** | Audial *perception* impairments | *Deafness*, *decreased hearing* -cognitive | **Neural impairments**, both **processing and producing** abilities | *Dyslexia*, *dementia*, *learning disorders*, *epilepsy* -motor | Impairments of both **gross and fine motor skills** | *Cerebral palsy*, *injury*, *stroke*, *deformity* +**cognitive** | **Neural impairments**, both **processing and producing** abilities | *Dyslexia*, *dementia*, *learning disorders*, *epilepsy* +**motor** | Impairments of both **gross and fine motor skills** | *Cerebral palsy*, *injury*, *stroke*, *deformity* > Important: Notice that we chose not to segregate **speech disabilities**. Remember that ability to speak can be compromised by **both motor and cognitive impairments**. diff --git a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/Accessibility/Interfaces/AccessibleUI.tutorial b/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/Accessibility/Interfaces/AccessibleUI.tutorial deleted file mode 100644 index 684362b..0000000 --- a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/Accessibility/Interfaces/AccessibleUI.tutorial +++ /dev/null @@ -1,68 +0,0 @@ -@Comment { - @Article(time: 30) { - - @Intro(title: "Create Accessible Interface") { - - A humble UI crash course - - Before doing anything with our apps let's make sure that we know what we're doing. Or at least have a required understanding to not make things worse. So we'll start with breaking down the conception of interfaces and what interface is considered accessible. - } - ## What is a user interface - ### Everything in-between a device and its user - Scientifically talking, a **user interface** is the space between a device and its user, and contains everything that makes the communication between the human and the machine possible. - - Any interface **provides and retrieves information**. The former ability is supposed to help the user to control the device, the latter allows this controlling. - - As a consequence, interfaces are built from various elements of different nature. Though all items provide information to some degree, not all of them are used to control. - - Therefore all elements can be separated into two groups: purely **informative** elements and **interactive** elements. - - But it is not sufficient for a collection of elements to be an interface. The items out of which the interface is built have to work together. Work in order to achieve a particular goal. So there must be a cohesion between them. - - ### User scenarios - Any application serves a particular **purpose**. Even if the task an application solves is not obvious there is one and it is determined by **what the application enables the user to do**. - - To get a better grip on the **concept**, let's answer the *"What this app is for?"* question for some common **types** of applications. - - | Application | Purpose | - | ----------------- | ----------------------------------------------------- | - | **A store** | To view and order the products available in the store | - | **A drawing app** | To create digital drawings on the device | - | **Settings** | To control the behaviour of the device | - | **A mobile game** | To entertain the user by various means | - | **A messenger** | To connect with other people using the device | - - As you can see the examples are indeed very different. But each of them equally has a purpose. The functionality of an app is built of user scenarios: possible sequences of actions done to achieve a particular task completion. - - ## What does accessibility adaption - ### Enables everyone to use the application - The one and only goal of accessibility adaption is to enable as many people to use the app. Which means that regardless of what scenarios are available for users without accessibility settings on they must be possible for a completion with help of assistive technology. - - ### Provides the equal experience - Additionally it is desired to provide accessible experience in the same manner as the "original" one, for example, just as easy and entertaining, but enabling the core functionality is the prior goal. There are few cases when it is impossible to save the quality of the experience: in cases where sensory translation loses the immersion. But unless there is an unescapable loss one has to consider the user experience to make products truly accessible. - - ## How to make accessible interfaces - To think with thoroughness. Not to use overlays, widgets, and not to mindlessly follow step-by-step guides. - - Accessibility is a part of inclusion. It is impossible to empower people without considering where they come from. Lack of empathy only results in misconceptions and no good product can be build on wrong predicaments. So to make sure you have the knowledge that is ready to be implemented read the rest of the book thoroughly and pay attention to the details. Be curious and critical: the smallest detail considered in your app can enable a huge range of people to use it. - - If you are ready to learn let's dive into accessibility. The topics discussed in this part of the book are presented by three categories: - - @Image(source: book-content, alt: "") - - ## Introduction - ## Interface's data exposure - ## Paving new trails - - - - - ## Have fun! - - - @Links(visualStyle: detailedGrid) { - - - - - } - } -} diff --git a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/InterfaceInteractions.md b/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/InterfaceInteractions.md deleted file mode 100644 index 8418533..0000000 --- a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/InterfaceInteractions.md +++ /dev/null @@ -1,97 +0,0 @@ -@Comment { - # Interface Interaction - - Different methods of controlling an interface - - @Metadata { - @PageColor(blue) - @TitleHeading("Controlling Options") - @PageImage( - purpose: icon, - source: "wheelchair", - alt: "") - @PageImage( - purpose: card, - source: "disabilities-card", - alt: "") - @CallToAction( - url: "https://www.apple.com/accessibility/", - purpose: link, - label: "General Knowledge") - } - - In [**Interface Perception**]() article we learnt that the information perceived by a person comes through multiple channels of receptive abilities and its interpretation is affected by possible limitations. - - ### Interfaces are just inputs and outputs - Moreover, we know that user interfaces are not only able to present the data but to receive it. Getting input is an essential task given to any computer to make the device operable. Operating computers enables its users to control the computational processes. - - Omitting the sophisticated language it just means that a computer is not solely a transmitter, but a receiver at the same time. - - ### Touchscreens implement both - Talking about the subject of our interest, people are able to operate modern mobile devices by interacting with its touchscreen. Any interface displayed on the screen consists of elements that are not only informational, but provide the option to be activated. - - ### Interactive elements of a user interface - Interactive elements of a user interface are called controls. But if a person can not operate a smartphone by precisely navigating and then activating a visible control on the screen? - - ## Physical limitations - - Definition of controls from above implies many pitfalls. - - ### Visual recognition - First of all, the controls available on the screen can be only distinguished visually, which is a problem. Not everyone is able to see, recognise or simply look at the screen. - - @Links(visualStyle: detailedGrid) { - - - } - - ### Precise navigation - Then there is activating these controls. To operate a mobile interface one has to press on a particular area of the touchscreen with their finger, which is also a problem. - - Not everyone has fingers. Moreover, having fingers doesn't guarantee that their owner is able to use them with the required dexterity. - - Regardless of their on the screen, graphic controls are still tiny because mobile device are tiny. Otherwise they wouldn't be mobile. - - Then there is responsiveness. Even the slightest touch on the screen is received. - - All that makes operating touchscreens an unbearable ordeal for people who lack fine motor skills or efficient visual recognition. Shaking hands, i.e. tremor, immobility of fingers or their absence, blindness disable a person from using controls. So how people are supposed to complete the task of using a smartphone if they simply can't? - - ## Item Selection - Here we are. Navigating to the control and activating as an integral process is called item selection. Both selection methods below work with the same set of elements on the screen, but the way the user comes to the control they want to activate is different. - - ### Direct selection - Complex graphic user interfaces were originally designed to be used with a pointing device. A pointing device is a mouse, a touchpad, a trackball, a stylus pen, an eye tracker -- everything that can be used to move a pointer, which is a symbol on the screen displaying the current position of the user in the interface, by providing physical input. - - Pointing devices allow direct input, which is a "free" focusing on an element on the screen by direct navigation. No iteration of other elements happening. - - > Note: Actually the iteration is happening, but the process is that fast and subconscious so it is incomparable to the explicit iteration. - - ### Indirect selection - On the other side of operating computers there is indirect selection. Indirect selection does not require precise physical aiming: this method goes through every element available on the screen without having to aim for it. The user either waits for the automatic selection frame to iterate to the item they want to activate or manually go to it if they are able to perform the action of focus. - - ### Interfacial elements hierarchy - To implement the indirect access, the assistive software takes the available elements of the screen and iterates through them in a particular order. - - ### Accessibility Tree - Talking about iOS devices, the order is taken from Accessibility Tree that represents a hierarchical structure of accessible elements. The iteration happens left to right or right to left depending on the language of the interface, top to bottom. - - ## Supporting indirect selection - And this is the most important thing we have to consider when designing accessible interface. To enable people use your application with indirect selection, you have to ensure that all controls are accessible and navigable. Moreover, it is crucial to be aware of the order of elements in your interface because indirect selection is essentially what VoiceOver is. Screen readers read the elements in the ordered manner, so it is crucial to structure the elements that way so the semantic model is properly comprehensible without having to perceive the interface layout visually. - - To know how to support indirect selection, and, thus, enable users of those assistive technology relying on it, take a look at the following articles: - - @Links(visualStyle: detailedGrid) { - - - - - - - - - - - - - } - - ### Have fun! - - ## See Also - - - - - - -} diff --git a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/MobileAccessibility.md b/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/MobileAccessibility.md deleted file mode 100644 index cf1a11d..0000000 --- a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/MobileAccessibility.md +++ /dev/null @@ -1,145 +0,0 @@ -@Comment { - # Accessibility of Mobile Applications - - What is **mobile accessibility** and its consequences - - @Metadata { - @PageColor(blue) - @TitleHeading("What Are We Talking About") - @PageImage( - purpose: icon, - source: "list", - alt: "") - @PageImage( - purpose: card, - source: "placeholder-image", - alt: "") - @CallToAction( - url: "https://www.apple.com/accessibility/", - purpose: link, - label: "General Knowledge") - } - - In this article we're going to overview the *concept* of **digital accessibility** and its application to **mobile devices** in general and **iOS** in particlar. - - ## Why support accessibility at the first place - - Perceive this part as a *disclaimer* of some kind. - @Image(source: "placeholder", alt: "") - - ### The clientele exists and is visible - To not rely on **common sense** solely, usage *statistics*, social *surveys* and other *market analyses* definitely show that **there are people in need of assistive technology support**. - @Image(source: "fifty-percent", alt: "") - - ### Nevertheless, accessibility is not yet widely considered - Despite the fact, it is still *globally uncommon* to have accessibility **considered**. The professional field is in shortage of *competent* specialists; organisations lack the **realisation** of how important it is to provide **equal access** to their products. - @Image(source: "placeholder", alt: "") - - Moreover, accessibility is essentially an engine of **people with disabilities inclusion**. Just as with any other **exclusion**, there are common **misconceptions** and **discrimination**. Having a disability is still **stigmatised** - the less *open-minded* society is the heavier it is. - @Image(source: "placeholder", alt: "") - - - ## Compliance and conformance - The answer to "Why support accessibility?" question is different for every person working *around* accessibility. Some people believe that [**accessible design**]() is an *immanent* part of **universal design** and conforming to **accessibility guidelines** makes the product better for everyone. Other chase the **auditory expansion** by PR stunts to attract good will. A few countries oblige organisations to make accessible products by **civil rights law** and such developers are **dodging lawsuits** by complying to the *standards*. - @Image(source: "placeholder", alt: "") - - ### Real accessibility is intentional - The more the production is influenced by *external* pressure the less accessible the result will be. Complying to **extrinsic standards** has *nothing* in common with providing accessible experience: only **empathy** allows people to consider others. It is impossible to support accessibility properly without a *clear* realisation of the situation and *genuine* motivation to change it. - @Image(source: "placeholder", alt: "") - In addition, **incorrect adoption** of accessibility guidelines leads to a dramatic **decrease of approachability** of the app. Integrating anything only increases **complexity** of applications so one has to be aware of the consequences of their actions. **The simpler interfaces are the more accessible they are.** - - ### Choice is yours - All in all, only the person themself decides *why* they want to enable more people to use the product whose development is under their influence. But remember that **accessibility of a digital product is a forceful approach to empower potential users with disabilities and enhance its interfacial design.** - - ### -- What do you mean by empowering? - Creating digital solutions is essentially **solving the problem of real world with help of technology**. For everyone. But talking about **people with health limitations**, using a **digital form** to get the services provided by a particular company **is the only** or **preferable way**. - @Image(source: "placeholder", alt: "") { - Ordering groceries online is a **lesser trial** for people with **limited mobility** than going to a local store - } - - - ### Accessibility is a privilege - **Integrating accessibility** into a project is a **difficult journey** for everyone, regardless of their specialty and position. [**iOS Accessibility Handbook**](https://vodgroup.github.io/AccessibilityDocumentation/documentation/iosaccessibilityhandbook) is here **to help**. We just advocate for accessibility and share that experience. - @Image(source: "placeholder", alt: "") - So, let's get some **work done**? - - ## Mobile accessibility for iOS - - First of all, let's get familiar with [**the subject**](). - - ### Accessibility is one of Apple's core values - - @Image(source: "placeholder", alt: "") - - Thanks to Apple's decision to protect **diversity** and invest to **accessibility** of their products, it is not a unworkable ordeal to create **accessible software** for iOS. - - @Image(source: "placeholder", alt: "") - - - ### Accessibility Features - It is so because **the system** supports an impressive [**range of assistive technology**]() and provides highly comprehensible **documentation**, including [**WWDC sessions**](https://developer.apple.com/wwdc23/topics/accessibility-inclusion/), [**API reference**](https://developer.apple.com/accessibility/) and [**promotional materials**](https://www.apple.com/accessibility). - - @Image(source: "placeholder", alt: "") - - ### Supporting Accessibility Features - The task of adopting accessibility may be narrowed to **understanding the accessible functional** and knowing how to make it work **within applications**. - - ### Interface tailoring - - To support **assistive technology** in your app its interface has to be comprehensible for **accessibility API**. - - @Image(source: "placeholder", alt: "") - - Constructing an interface out of **default elements** majorly covers the functionality of [**Accessible Features**](), though the **experience** of automatically generated interface will not be as... *delightful* as the one **touched by a human**. Again, **there is no real accessibility if not intended**. - - @Image(source: "placeholder", alt: "") - - Having **custom elements** designed *specifically* for your interface requires a little bit more work done on supporting [**Accessible Features**]() but it's definitely not exhausting too. - - This way **accessibility integration is about providing additional data about the interface elements in the code**. - - ### UIKit and SwiftUI - - @Image(source: "placeholder", alt: "") - - Both of two possible **user interface frameworks**, [**UIKit**](https://developer.apple.com/documentation/uikit) and [**SwiftUI**](https://developer.apple.com/xcode/swiftui/) *equally* provide accessible underlayment for applications built with their use. - - @Image(source: "placeholder", alt: "") - - In the book we are going to study [**iOS Accessibility**]() by **conceptions** presents in *any* other interface, so it is not that important to focus on a particular framework. Nevertheless **both UIKit and SwiftUI implementations are provided for *every* code sample** if possible. - - @Image(source: "placeholder", alt: "") - - ### -- But what about accessible design? - - @Image(source: "placeholder", alt: "") - - Once the foundation, which is required **skills** and **tools** to construct **accessible interfaces**, is set there is [**accessibility design**](). It is just important **to not exclude people** by *inconvenient* accessible design as to *enable* possibility to use the product with support of assistive technology. - - ### -- Ok. So accessible UI, accessible UX. - - Kind of. But *no* accessibility implemented for an application will *last* (or do good at all) without proper **changes in the organisational work**. So if you are already **familiar** with the concepts behind assistive technology and its support, there is [**Enterprise**]() volume of the book. It tells how to *apply* your knowledge on a **bigger scale**. - - @Links(visualStyle: compactGrid) { - - - - - - - } - - ## Accessibility Integration Strategy - - Well, enough talking. We know what job awaits, time to get some **work** done. - - ### iOS Accessibility Guide - The book's [**guidelines**]() are structured *that* way so there is some **entry-level tasks to enable equal access** and vast resources on **polishing accessible experience**. - - @Image(source: book-content, alt: "") - - The *whole* curriculum is located at the [**table of contents**](). - - @Image(source: roadmap, alt: "") - - To start right with **practicing** something new, go to the [**basic**]() or the [**advanced**]() level **heading pages**, according to *what* you want to learn. That's it for now. - - ## Have fun! -} diff --git a/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/iOS Accessibility/iOSAccessibility.md b/Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/iOS Accessibility/iOSAccessibility.md similarity index 100% rename from Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/Theory/iOS Accessibility/iOSAccessibility.md rename to Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/iOS Accessibility/iOSAccessibility.md