testing.md + spelling

README.md

@@ -30,11 +30,11 @@ To focus on the applications of Accessibility Features.
 
 ### Articles
 To study the concepts.
-- Accessibility Properties in Code: How to Use Them. A brief overview of **implenting accessibility in apps**.
+- Accessibility Properties in Code: How to Use Them. A brief overview of **implementing accessibility in apps**.
 - Accessibility Features Explained: How People Use Assistive Technology. A thorough **description of the concepts** and its technological implementations in order **to provide a better understanding** of how it all works.
 
 ## — Can I contribute to the project? 
-Yes, **everyone is welcome to influence the project**, especially considering a non-commercial nature of it. It can be done by **comitting *ideas* and *fixes* to this repository** or **straightforwardly reaching someone from the team**. A few examples of doing this:
+Yes, **everyone is welcome to influence the project**, especially considering a non-commercial nature of it. It can be done by **committing *ideas* and *fixes* to this repository** or **straightforwardly reaching someone from the team**. A few examples of doing this:
 - **describe a problem** or **discuss on the topic** in **[Issues](https://github.com/VODGroup/AccessibilityDocumentation/issues)**; 
 ![issues](./Sources/iOSAccessibilityHandbook/Screenshots/issues~dark.png#gh-dark-mode-only)
 ![issues](./Sources/iOSAccessibilityHandbook/Screenshots/issues~light.png#gh-light-mode-only)

Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/AdaptionTechniques/AdaptionStrategy.tutorial

@@ -13,7 +13,7 @@
             - <doc:AdaptionStrategy>
         }
 
-        Otherwise you may start straight from the first guide or a tutorial of your particular interest — the separeted materials are *self-sufficient* and their cohesion is decorative. 
+        Otherwise you may start straight from the first guide or a tutorial of your particular interest — the separated materials are *self-sufficient* and their cohesion is decorative. 
     }
 
     @Volume(name: "Making Accessibility Work") {
@@ -119,7 +119,6 @@
 
             How to test accessible apps.
 
-            @TutorialReference(tutorial: "doc:AccessibilityQA")
             @TutorialReference(tutorial: "doc:UnitTesting")
             @TutorialReference(tutorial: "doc:UITesting")
         }

Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/AdaptionTechniques/Advanced/VerticalSwipes/AdjustableElements/AdjustableElements.tutorial

@@ -85,7 +85,7 @@
 
 
                     @Justification(reaction: "Try again!") {
-                        Voice Control is mostly used by people who are able to see. In such case percieving elements as separate buttons is preferred.
+                        Voice Control is mostly used by people who are able to see. In such case perceiving elements as separate buttons is preferred.
                     }
                 }
             }

Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/AdaptionTechniques/Essentials/Describe/DescribeElements/DescribeElements.tutorial

@@ -1,8 +1,8 @@
 @Tutorial(time: 15) {
     @Intro(title: "Elements Described For Assistive Technology") {
-        In this tutorial we're going to discuss unquestionably the most important thing to make an interface accesible — properly **describe its elements** for both users and assistive technology. 
+        In this tutorial we're going to discuss unquestionably the most important thing to make an interface accessible — properly **describe its elements** for both users and assistive technology. 
 
-        ## What elements are considered accesible?
+        ## What elements are considered accessible?
         To enable [accessibility applications](<doc:AccessibilityFeatures>) work as intended for a particular *element* it has to have *certain properties* specified. Sometimes elements inherit such information by default — if they are of an *accessible class* (like [`UIButton`](https://developer.apple.com/documentation/uikit/uibutton)), but most of the times we have to manually set properties for the items present on the screen to make it not only *function*, but *be pleasant* to use.
 
         Let's go over *core* attributes of [`UIAccessibilityElement`](https://developer.apple.com/documentation/uikit/uiaccessibilityelement) to figure out **why** and **when** we should use them.
@@ -17,7 +17,7 @@
             We are going to deal with `Label` and `Value` at the same time as they are similar in their nature: both are *localised strings* and of *informative purpose*. Firstly, let's take a closer look at each of them.
 
             ### Label — Identification
-            [`accessibilityLabel`](https://developer.apple.com/documentation/uikit/uiaccessibilityelement/1619577-accessibilitylabel) is the *main property* of the element's description. It is said that `Label` "succintcly identifies the element", which is, translated to human-readable language, means that **users must be able to get everything they need to get about the element by only hearing its label**. Or *call* this exact element by calling its name. Depends on the technology.
+            [`accessibilityLabel`](https://developer.apple.com/documentation/uikit/uiaccessibilityelement/1619577-accessibilitylabel) is the *main property* of the element's description. It is said that `Label` "succinctly identifies the element", which is, translated to human-readable language, means that **users must be able to get everything they need to get about the element by only hearing its label**. Or *call* this exact element by calling its name. Depends on the technology.
 
             @Image(source: placeholder-image.png, alt: "")
         }
@@ -33,7 +33,7 @@
                 Since there is nothing more than a *very specific* piece of data stored in the element we **use its `Value` as `Label`**. 
 
                 > Notice:
-                There is accessibilityValue property, but in this particular case it is unreasonable to separate the fact that it's "Views" and its number into two different properties. It would be an  inconvinient experience for users.
+                There is accessibilityValue property, but in this particular case it is unreasonable to separate the fact that it's "Views" and its number into two different properties. It would be an  inconvenient experience for users.
 
                 @Image(source: chapter-placeholder.png, alt: "")
             }
@@ -44,7 +44,7 @@
         @ContentAndMedia {    
 
             ### Value — Details
-            Then there is [`accessibilityValue`](https://developer.apple.com/documentation/objectivec/nsobject/1615117-accessibilityvalue). Basically this property is used to store any *additional information* about the element that is unnesseccary for `Label` to be, Lord forgive me, *succint*.
+            Then there is [`accessibilityValue`](https://developer.apple.com/documentation/objectivec/nsobject/1615117-accessibilityvalue). Basically this property is used to store any *additional information* about the element that is unnecessary for `Label` to be, Lord forgive me, *succinct*.
 
             @Image(source: placeholder-image.png, alt: "")
         }
@@ -62,7 +62,7 @@
             }
 
             @Step {
-                Everything else ever possible goes to `Value`: songs' author, the album it belongs to, the date of its release, its lenght and so on. There may be many songs sang by "The Police", but only one "Message In A Bottle" — thus we define properties. 
+                Everything else ever possible goes to `Value`: songs' author, the album it belongs to, the date of its release, its length and so on. There may be many songs sang by "The Police", but only one "Message In A Bottle" — thus we define properties. 
 
                 @Image(source: chapter-placeholder.png, alt: "")
             }
@@ -78,9 +78,9 @@
     @Section(title: "Label vs Value") {
         @ContentAndMedia {    
             ### Fine Line Between Label And Value
-            To properly adapt an interface for various Accessibility Features one has to clearly differintiate between these two traits. For example, `Label` is heavily exploited by [`Voice Control`](<doc:VoiceControl>) and has to be independent of unneccessary information to avoid ambiguity. In the meantime `Value` is that part of element's description that is changable by [`AdjustableTrait`](<doc:AdjustableElements>)'s usage.
+            To properly adapt an interface for various Accessibility Features one has to clearly differentiate between these two traits. For example, `Label` is heavily exploited by [`Voice Control`](<doc:VoiceControl>) and has to be independent of unnecessary information to avoid ambiguity. In the meantime `Value` is that part of element's description that is changeable by [`AdjustableTrait`](<doc:AdjustableElements>)'s usage.
 
-            To learn how to fluently use these traits let's work on some examplary elements.
+            To learn how to fluently use these traits let's work on some exemplary elements.
         }
 
         @Steps {
@@ -111,7 +111,7 @@
 
         @Steps {
             @Step {
-                Going back to the examples we've already worked with, the "Song" example should have [`header`](https://developer.apple.com/documentation/uikit/uiaccessibilitytraits/1620170-header) trait. This trait indicates that the element is essentially a divider, such as *titles* and *navigation bars*. Users percieve such elements as a section's name. 
+                Going back to the examples we've already worked with, the "Song" example should have [`header`](https://developer.apple.com/documentation/uikit/uiaccessibilitytraits/1620170-header) trait. This trait indicates that the element is essentially a divider, such as *titles* and *navigation bars*. Users perceive such elements as a section's name. 
 
                 @Image(source: placeholder-image.png, alt: "")
             }
@@ -138,7 +138,7 @@
             }
 
             @Step {
-                Pay attention that *action buttons* should have **short and comrehensible labels that describe what this button does**. Do not use the word "button" in its label: if spoken by [`VoiceOver`](<doc:VoiceOver>), it is doubled since having `Trait` specified causes the screenreader to tell the user that the element is a button.
+                Pay attention that *action buttons* should have **short and comprehensible labels that describe what this button does**. Do not use the word "button" in its label: if spoken by [`VoiceOver`](<doc:VoiceOver>), it is doubled since having `Trait` specified causes the screenreader to tell the user that the element is a button.
 
 
                 @Image(source: placeholder-image.png, alt: "")
@@ -151,7 +151,7 @@
             }
 
             @Step {
-                By its definition a `button` is an element that can be *pressed*. So if there is a *complex* element that is hard to identify as a `button` from the first sight you should remember that if it's interactable it's still a button.
+                By its definition a `button` is an element that can be *pressed*. So if there is a *complex* element that is hard to identify as a `button` from the first sight you should remember that if it's intractable it's still a button.
 
 
                 @Image(source: placeholder-image.png, alt: "")
@@ -201,7 +201,7 @@
 
             [`accessibilityHint`](https://developer.apple.com/documentation/objectivec/nsobject/1615093-accessibilityhint) is a *description* of what happens if the user *interacts* with an element. But there is a tricky moment.
 
-            *Every* interactive element has its own `Hint` specified *by default*. The problem is that these hints are repitive and **majority of `Accessibility Features` users turn it off** so there is very little chance that someone will ever see your *customized* hints. 
+            *Every* interactive element has its own `Hint` specified *by default*. The problem is that these hints are repetitive and **majority of `Accessibility Features` users turn it off** so there is very little chance that someone will ever see your *customised* hints. 
 
             The reason why you should customise the hints for your controls is that if there are [`Custom Actions`](<doc:Rotor>) a curious user may survey them in order to see **how *well* the application is adapted**.
 

Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Introduction/AccessibilityFeatures/VoiceOver/VoiceOver.md

@@ -14,3 +14,19 @@ Helps blind or low-visioned persons to use a phone by listening audio descriptio
 ![VoiceOver gestures](voiceOver-gestures)
 
  [Video how to navigate by VoiceOver](https://www.youtube.com/watch?v=qDm7GiKra28)
+
+## Зачин
+
+## Что это такое 
+
+## Аудитория
+
+## Как пользоваться (+ видео михаила рубанова)
+
+## Сценарии 
+
+## Пара слов о поддержке этого прикола 
+
+## Послать в соответствующие туториалы
+
+

Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Processes/Processes/Maintenance /Maintenance.tutorial

@@ -0,0 +1,28 @@
+@Tutorial(time: 15) {
+    @Intro(title: "Accessibility Maintenance") {
+        If supported, any application grows in complexity even if there is no additional functionality added. 
+
+        @Image(source: image-placeholder, alt: "")
+    }
+
+    @Section(title: "No Fucking Idea") {
+        @ContentAndMedia {
+            Text!
+
+            @Image(source: chapter-placeholder, alt: "")
+        }
+
+        @Steps {
+            @Step {
+                Text?
+
+                @Image(source: image-placeholder, alt: "")
+            }
+            @Step {
+                Text.
+
+                @Image(source: chapter-placeholder, alt: "")
+            }
+        }
+    }
+}

Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/Processes/Processes/Testing/Testing.tutorial

@@ -0,0 +1,27 @@
+# Accessibility Quality Assurance
+
+Testing is an essential part of production. Just as any other functionality, accessibility of an app has to be tested to make sure that the app is approachable and intuitive.
+
+@Metadata {
+    @DisplayName("Accessibility Quality Assurance")
+    @PageImage(
+        purpose: icon, 
+        source: "icon", 
+        alt: "")
+    @PageColor(blue)
+}
+
+## Testing Team
+To test whether your app is accessible it may be helpful to have someone who is a regular user of Accessibility Features. For example, a blind person. But is it strictly required for making an approachable product?
+@Image(source: placeholder-image, alt: "")
+
+
+## Accessibility VS UX
+Accessibility Testing sometimes exposes issues of user experience nature which have nothing to do with accessibility adaption. See the tutorial below to distinguish between these kinds of bugs and know how to deal with them in accordance. 
+
+## Standards And Certification
+Accessibility initiatives often come up with their vision of what makes an application accessible. Let's' go through some of the most common guidelines to see how to make your app legit.
+
+## Automated Testing
+As for today there are more than enough tools to cover certain accessibility checks by automated testing that help testers to organise their work. Such instruments are found helpful to zero the chance of overseeing something and omitting the need to repetitively check the code. 
+

Sources/iOSAccessibilityHandbook/iOSAccessibilityHandbook.docc/Pages/iOSAccessibilityHandbook.md

@@ -45,7 +45,7 @@ At the moment the project's form is defined by being a *documentation catalog* (
 To contribute to the project visit its [GitHub page](https://github.com/VODGroup/AccessibilityDocumentation) and see the instruction of how one may help.
 
 ### Contributors
-The resources are provided by **Mikhail Rubanov**, Head of Mobile Development at [**Dodo Brands**](https://dodobrands.io), accesisibility activist and the author of ["**About Accesibility on iOS**"]( https://rubanov.dev/a11y-book) book. Examplary and illustrative materials are based on his *working experience*. 
+The resources are provided by **Mikhail Rubanov**, Head of Mobile Development at [**Dodo Brands**](https://dodobrands.io), accessibility activist and the author of ["**About Accesibility on iOS**"]( https://rubanov.dev/a11y-book) book. Exemplary and illustrative materials are based on his *working experience*. 
 @Image(source: "aboutAccessibility-sample", alt: "-")
 
 ### VoiceOver Designer
@@ -95,3 +95,4 @@ Reading the book you may sometimes notice screenshots of iOS applications with *
 ### What's Next?
 - <doc:WhatsNext>
 - <doc:Processes>
+- <doc:Testing>