Merge pull request #28 from infinum/wcag-2.2-aa

Add WCAG 2.2 (AA) for iOS

README.md

@@ -20,6 +20,7 @@ This repository contains mobile standards created for mobile platforms. It inclu
        * [Operable](docs/guidelines/principles/operable_principle.md)
        * [Understandable](docs/guidelines/principles/understandable_principle.md)
        * [Robust](docs/guidelines/principles/robust_principle.md)
+       * [Guideline checklist](docs/guidelines/principles/guideline_checklist.md)
 
     * [Testing accessibility features](docs/testing/testing.md)
 

docs/guidelines/platforms/ios/guideline_robust_ios.md

@@ -4,82 +4,69 @@
 
 Content must be robust enough that it can be interpreted by a wide variety of mobile devices, including those which use accessibility features.
 
-## Compatible
+## Compatible (WCAG 4.1)
 
 Maximize compatibility with current and future devices, taking into account the accessibility features that they might be using.
 
-### Parsing
+### Name, Role, Value (WCAG 4.1.2 - Level A)
 
-All user-visible content be grouped logically and assigned identifiers appropriately.
+User interface elements should be clearly defined by their name ([accessibility label](https://developer.apple.com/documentation/objectivec/nsobject/1615181-accessibilitylabel) & [accessibility hint](https://developer.apple.com/documentation/objectivec/nsobject/1615093-accessibilityhint)), the role that they have (accessibility identifier), and the value they carry([accesibility value](https://developer.apple.com/documentation/objectivec/nsobject/1615117-accessibilityvalue)). The app should be able to notify the user if any of these parameters change programmatically without user input (or the changes should be reflected in the element's accessibility attributes) so that the user remains aware of what this element does at all times.
 
-*This guideline covers point 4.1.1 Parsing - Level A of the WCAG standard.*
+> This guideline covers point *4.1.2 Name, Role, Value - Level A of the WCAG standard.*
 
 #### ✅ Success technique(s)
 
-##### Using accessibility identifiers
-
-Every user interface element should have a unique [accessibility identifier](https://developer.apple.com/documentation/uikit/uiaccessibilityidentification/1623132-accessibilityidentifier), which will define it. Identifiers should not be reused except where this is by design (i.e. the same exact element exists in several different locations). This property is not actually part of the accessibility context but is rather used to differentiate between objects programmatically.
+Every user interface element should have an accessibility label that can be used by VoiceOver.
 
 ```swift
-submitFormButton.accessibilityIdentifier = "submit-form-button"
+addButton.accessibilityLabel = "Add"
+addButton.accessibilityHint = "Adds an entry in the list"
 ```
 
-There are two approaches for iterative elements, such as lists and tables; if the elements don't need to be distinguishable from each other for UI testing purposes (or some other explicit need), then using a single accessibility identifier for all elements is acceptable. Otherwise the identifier could be suffixed with an index or more concrete information regarding its meaning.
+For elements that carry a value, such as a label, the accessibility value should be used to represent this value. If the accessibility value is not set, then the actual value (in this case, the text value) will be read.
 
 ```swift
-func tableView(
-    _ tableView: UITableView,
-    cellForRowAt indexPath: IndexPath
-) -> UITableViewCell {
-    let cell = tableView.dequeueReusableCell(withIdentifier: identifier)
-    ...
-
-    cell.accesibilityIdentifier = "login-form-cell"
-
-    // or
-
-    cell.accesibilityIdentifier = "login-form-cell-\(indexPath.row)"
-
-    ... 
-    return cell
-}
+titleLabel.text = "Entries"
+titleLabel.accessibilityValue = "Entries list"
 ```
 
 #### 🚫 Failures
 
-Duplicate identifiers are used for elements that are essentially different in their action or role.
+Not providing accessibility identifiers for user interface elements.
+
+Implementing custom controls that are unfamiliar to the users and don't carry the necessary accessibility identifying information as defined in this guideline.
 
-Elements are not grouped or are badly organized on the screen, which prevents accessibility features from quickly and efficiently moving through them.
+Changing the value or role of a user interface element without adjusting its identifier programmatically.
 
-### Name, Role, Value
+### Status messages (WCAG 4.1.3 - Level AA)
 
-User interface elements should be clearly defined by their name ([accessibility label](https://developer.apple.com/documentation/objectivec/nsobject/1615181-accessibilitylabel) & [accessibility hint](https://developer.apple.com/documentation/objectivec/nsobject/1615093-accessibilityhint)), the role that they have (accessibility identifier), and the value they carry([accesibility value](https://developer.apple.com/documentation/objectivec/nsobject/1615117-accessibilityvalue)). The app should be able to notify the user if any of these parameters change programmatically without user input (or the changes should be reflected in the element's accessibility attributes) so that the user remains aware of what this element does at all times.
+The guideline states that status messages should be programmatically determinable by the user. 
+This means that the user should be able to know the status of the app at any given time without having to interact with it.
+
+On mobile this means that the user should be able to know if the current state has been changed - which is especially important for users who rely on screen readers.
 
-*This guideline covers point 4.1.2 Name, Role, Value - Level A of the WCAG standard.*
+> This guideline covers point *4.1.3 Status messages - Level AA of the WCAG standard.*
 
 #### ✅ Success technique(s)
 
-Every user interface element should have a unique accessibility label that can be used by VoiceOver.
+To satisfy this guideline, the app should provide a way for the user to know the current status of the app at any given time. This can be in situations like;
 
-```swift
-addButton.accessibilityLabel = "Add"
-addButton.accessibilityHint = "Adds an entry in the list"
-```
+- search results are being loaded,
+- cooking time has changes,
+- items has been added to the cart,
+- etc.
 
-For elements that carry a value, such as a label, the accessibility value should be used to represent this value. If the accessibility value is not set, then the actual value (in this case, the text value) will be read.
+Based on changes like that, the `UIAccessibility.Notification` can be used to notify the user of the change.
 
 ```swift
-titleLabel.text = "Entries"
-titleLabel.accessibilityValue = "Entries list"
+UIAccessibility.post(notification: .announcement, argument: "5 results found.")
 ```
 
-#### 🚫 Failures
-
-Not providing accessibility identifiers for user interface elements.
+For more information about examples and success criteria, please refer to the [Understanding WCAG 4.1.3 - Status messages](https://www.w3.org/WAI/WCAG21/Understanding/status-messages) page.
 
-Implementing custom controls that are unfamiliar to the users and don't carry the necessary accessibility identifying information as defined in this guideline.
+#### 🚫 Failures
 
-Changing the value or role of a user interface element without adjusting its identifier programmatically.
+Not providing a way for the user to know the current status of the application at any given time.
 
 ⎯
 

docs/guidelines/platforms/ios/guideline_understandable_ios.md

@@ -4,19 +4,19 @@
 
 Information and the operation of the user interface must be understandable.
 
-## Readable
+## Readable (WCAG 3.1)
 
 Make text content readable and understandable.
 
-### Language of Page
+### Language of Page (WCAG 3.1.1 -Level A)
 
 The default human language of an App can be programmatically determined.
 
-*This guideline covers point 3.1.1 Language of Page - Level A of the WCAG standard.*
+> This guideline covers point *3.1.1 Language of Page - Level A of the WCAG standard.*
 
 #### ✅ Success technique(s)
 
-Specify the default language of the application in the HTTP headers of the API calls. 
+Specify the default language of the application in the HTTP headers of the API calls.
 
 ```text
 Content-Language: de-DE
@@ -41,15 +41,36 @@ Bundle.setLanguage(language)
 
 Also, every app should be developed as a localizable app. Even if it seems that it makes no sense in the beginning or that all of the intended audience speak a single language, it can still happen that some users will not be able to use that language. here is always a possibility that your app will scale to different language regions or parts of your code will be reused on different projects which _do_ use localization.
 
-## Predictable
+### Language of Parts (WCAG 3.1.2 - Level AA)
+
+To be able to give the best possible experience to users, the language of each part of the app should be programmatically determined. With that in mind, VoiceOver should be able to read the content in the correct language.
+
+> This guideline covers point *3.1.2 Language of Parts - Level AA of the WCAG standard.*
+
+#### ✅ Success technique(s)
+
+Due to need for VoiceOver to read the content in the correct language, the part of the content should get the correct language interpretation.
+
+On iOS, this can be done by using `NSAttributedStrings` and setting the [speech attributes](https://developer.apple.com/documentation/objectivec/nsobject/uiaccessibility/speech_attributes_for_attributed_strings) for the specific part of the string.
+
+```swift
+let attributedString = NSAttributedString(
+    string: "Arc de Triomphe",
+    attributes: [.accessibilitySpeechLanguage: "fr-FR"]
+)
+```
+
+If the whole text (label) is using the same language, the `accessibilityLanguage` property can be set in that case instead.
+
+## Predictable (WCAG 3.2)
 
 Make mobile apps appear and operate in predictable ways.
 
-### On Focus & On Input
+### On Focus & On Input (WCAG 3.2.1 and 3.2.2 - Level A)
 
 Receiving focus on or interacting with any component should not initiate a change of context unless previously announced.
 
-*This technique covers points 3.2.1 On Focus - Level A & 3.2.2 On Input - Level A of the WCAG standard.*
+> This technique covers points *3.2.1 On Focus - Level A and 3.2.2 On Input - Level A of the WCAG standard.*
 
 #### ✅ Success technique(s)
 
@@ -101,15 +122,45 @@ func textFieldDidBeginEditing(_ textField: UITextField) {
 }
 ```
 
-## Input Assistance
+### Consistent Navigation (WCAG 3.2.3 - Level AA)
+
+For users, it is important to have a consistent navigation experience throughout the app. With that satisfied, users can easily predict where they are and where they can go next.
+
+> This technique covers point *3.2.3 Consistent Navigation - Level AA of the WCAG standard.*
+
+#### ✅ Success technique(s)
+
+To satisfy this criterion, try to keep the navigation structure consistent, with elements like tab bar (and tab bar items), search bar or navigation bar always in the same place, and with the same functionality (when possible).
+
+#### 🚫 Failures
+
+Changing the position of elements or making the app behaviour unconsistent can confuse users and make it harder for them to navigate through the app, which results in failure to satisfy this criterion.
+
+### Consistent Identification (WCAG 3.2.4 - Level AA)
+
+While using the application, components that have the same functionality should be identified consistently.
+
+> This technique covers point *3.2.4 Consistent Identification - Level AA of the WCAG standard.*
+
+#### ✅ Success technique(s)
+
+To satisfy this criterion, try to keep the identification of the same components consistent throughout the application. Use properties like `accessibilityLabel` and `accessibilityHint` with other parts of implementation (traits or custom actions) to make sure they are defined and function in a same way.
+
+To simplify this, try to think about a simple download icon, which should have the same accessibility label across the application (if possible). If elements are defined in a same way, users won't get confused and will know how to use the application and recognize its components.
+
+#### 🚫 Failures
+
+As a failure, we can consider components and elements that have different identification across the application. This can confuse users and make it harder for them to use the application.
+
+## Input Assistance (WCAG 3.3)
 
 Help users avoid and correct mistakes when interacting with the app.
 
-### Error Identification
+### Error Identification (WCAG 3.3.1 - Level A)
 
 If an input error is automatically detected, the item in error is identified, and the error is clearly described to the user in text.
 
-*This technique covers point 3.3.1 Error Identification - Level A of the WCAG standard.*
+> This technique covers point *3.3.1 Error Identification - Level A of the WCAG standard.*
 
 #### ✅ Success technique(s)
 
@@ -148,11 +199,11 @@ generator.notificationOccurred(.success)
 
 Preventing some action or flow from continuing because an error was detected but not communicating to the user how/when the error was made and/or what needed to be done to correct it.
 
-### Labels or Instructions
+### Labels or Instructions (WCAG 3.3.2 - Level A)
 
 Labels or instructions are provided when content requires user input.
 
-*This technique covers point 3.3.2 Labels or Instructions - Level A of the WCAG standard.*
+> This technique covers point *3.3.2 Labels or Instructions - Level A of the WCAG standard.*
 
 #### ✅ Success technique(s)
 
@@ -177,6 +228,91 @@ usernameHolderView.shouldGroupAccessibilityChildren = true
 
 A user enters some data into a user interface element without knowing what the end result is and/or triggering an unannounced change of context in the process.
 
+### Error Suggestion (WCAG 3.3.3 - Level AA)
+
+To provide the best user experience, the application should suggest solutions for input errors when they are detected.
+
+> This technique covers point *3.3.3 Error Suggestion - Level AA of the WCAG standard.*
+
+#### ✅ Success technique(s)
+
+When an error is detected, the application should provide a suggestion for the user on how to correct it. This can be done by providing a hint or a description of the error or providing a suggestion on how to correct it.
+
+This is not just an accessibility feature, but also a usability feature, as it helps users to understand what they did wrong and how to correct it. Of course, if the suggestion is presented, this should be done in an accessible way (e.g. using an accessibility label).
+
+*Note: This should be avoided if the error suggestion would jeopardize the security or purpose of the content.*
+
+### Error Prevention (Legal, Financial, Data) (WCAG 3.3.4 - Level AA)
+
+To prevent users from making mistakes, the application should provide a mechanism before finalizing a transaction that involves legal, financial, or data-sensitive actions.
+
+> This technique covers point *3.3.4 Error Prevention (Legal, Financial, Data) - Level AA of the WCAG standard.*
+
+#### ✅ Success technique(s)
+
+To satisfy this criterion, the app should provide at least one of the following mechanisms:
+
+- **Reversible**: The submission is reversible.
+- **Checked**: Data entered by the user is checked for input errors and the user is provided with an opportunity to correct them.
+- **Confirmed**: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
+
+Based on the type of the application, the mechanism should be implemented in a way that is most suitable for the user and the application's purpose.
+
+### Redundant Entry (WCAG 3.3.7 - Level A)
+
+Ensure that multi-step processes are user-friendly by not requesting the same information multiple times in a session, as this can be challenging for those with cognitive disabilities. This approach enhances accessibility by reducing memory load and simplifying tasks.
+
+> This technique covers point *3.3.7 Redundant Entry - Level A of the WCAG standard.*
+
+#### ✅ Success technique(s)
+
+Information previously entered by or provided to the user that is required to be entered again in the same process is either:
+
+- auto-populated, or
+- available for the user to select.
+
+Techniques mentioned above does not apply to the following cases:
+
+- when re-entering the information is essential,
+- when the information is required to ensure the security of the content, or
+- when previously entered information is no longer valid.
+
+### Accessible Authentication (Minimum) (WCAG 3.3.8 - Level AA)
+
+To make authentication accessible to all users, the application should not require a cognitive function test unless that step provides at least one of the following:
+
+- **Alternative**: Another authentication method that does not rely on a cognitive function test.
+- **Mechanism**: A mechanism is available to assist the user in completing the cognitive function test.
+- **Object Recognition**: The cognitive function test is to recognize objects.
+- **Personal Content**: The cognitive function test is to identify non-text content the user provided to the application.
+
+> This technique covers point *3.3.8 Accessible Authentication (Minimum) - Level AA of the WCAG standard.*
+
+#### ✅ Success technique(s)
+
+Some of the success techniques to satisfy this criterion are:
+
+- Support for text (copy and) paste to reduce the cognitive burden of re-typing
+- Support for password entry by password managers
+- Support for biometric authentication
+- Support for email link authentication
+- Support for OAuth authentication
+
+#### 🚫 Failures
+
+To fail this criterion, users should be required to complete a cognitive function test to authenticate themselves or enter the values in a different way than they were originally created/provided.
+
+Some examples:
+
+- Write 2nd and 5th character of your password
+- Write every character of the verification code in a separate field
+
+## Other understandable guidelines
+
+This section contains guidelines that may not be applicable to the mobile (iOS) platform or its criteria is not the responsibility of the mobile team. Still, take into account that those guidelines need to be satisfied.
+
+- [WCAG 3.2.6 Consistent Help - Level A](https://www.w3.org/WAI/WCAG22/quickref/#consistent-help)
+
 ⎯
 
 [← Understandable principle](../../principles/understandable_principle.md "Understandable principle")

docs/guidelines/principles/accessibility_principles_and_examples.md

@@ -11,6 +11,10 @@ In the following chapters, information about satisfying accessibility guidelines
 * [Understandable principle and guidelines](understandable_principle.md "Understandable principle and guidelines")
 * [Robust principle and guidelines](robust_principle.md "Robust principle and guidelines")
 
+Alongside the guidelines and examples, you can check the list of requirements that should be satisfied for each guideline:
+
+* [Guideline checklist](guideline_checklist.md "Guideline checklist")
+
 ⎯
 
 [← Accessibility guidelines](../accessibility_guidelines.md "Accessibility guidelines")