diff --git a/Sources/AccessibilityDocumentation/Documentation.docc/Articles/1. Basic/DescribeElements.md b/Sources/AccessibilityDocumentation/Documentation.docc/Articles/1. Basic/DescribeElements.md index 43ee5ec..8e2e7f5 100644 --- a/Sources/AccessibilityDocumentation/Documentation.docc/Articles/1. Basic/DescribeElements.md +++ b/Sources/AccessibilityDocumentation/Documentation.docc/Articles/1. Basic/DescribeElements.md @@ -1,84 +1,94 @@ -# Describe elements +# Describing Elements -Core properties that describes element for VoiceOver +In this article we're going to go over core *properties* that **describe *elements* for assistive technologies**. -To describe element we can use label, value and trait (like a type) +Elements *description* is an essential part for the functioning of **VoiceOver**. This technology is aimed to ***tell* users what's happening on the screen**. -## Label +Nevertheless **Voice Control** and **Switch Control** also benefit from explicitly stated descriptional *properties* in particular cases. + +To describe an element we can **specify three properties**: a *label*, a *value* and a *trait*. Let's get familiar with each of them. + + +## `accessibilityLabel` — Label @Row { @Column(size: 1) { ``Book/accessibilityLabel`` - The main property is `accessibilityLabel` – defines element's name. It should be name in one or two words for buttons or represents full text from `UILabel` + `accessibilityLabel` is the *main* property of the element's description. **It can't be omitted**. Usually **defines the element's *name***. - > Tip: Voice Control can have synonyms for label. Check ``Book/accessibilityUserInputLabels`` for more details. + If the element is a *button* it should be **labeled by a *single word* or a *collocation* that represent the *action* it does**. + + If there is *text* in `UILabel` it should be copied to `accessibilityLabel`. + + > Tip: **Voice Control** can use **a list of synonyms as its label**. It is done so users may ***address* to a single element by multiple options**. Check ``Book/accessibilityUserInputLabels`` for more details. } @Column { - **Examples:** - - *1.4 billions views* – just the fact under the video - - *Never Gonna Give You Up* – song title that describes screen's content - - *Next* – for button that skip a song in audio player. The button can be just icon, but we provide textual description for it. - - *Pizza Pepperoni* – for cell in the menu. The cell can contain an image of the pizza, but we not point on it in textual description, just describe what the cell is about. - - *Size* – for segmented control on product card - - *Brightness* – for slider in Control Center + **Some examples:** + - *1.4 billions views* is to state a fact under a video.. + - *Never Gonna Give You Up* is a song's name. + - *Next* is a button that goes to the next element. The button itself may be represented as a graphic icon, but to adapt the interface one has to provide textual description for elements that are not verbalised. + - *Pizza Pepperoni* is a cell in a restaraunt's menu. Cells may contain a wide range of media types, and in this particular case there is most likely a picture of the pizza — don't focus on this fact. Focus on the information that the picture provides. + - *Size* is a segmented control in a product card. + - *Brightness* is a slider in Control Center. } } -## Value +## `accessibilityValue` — Value @Row { @Column(size: 2) { ``Book/accessibilityValue`` - `AccessibilityValue` is optional second part of the element's description. It can contain additional details or represents current value of the element + `accessibilityValue` is an *optional* property of the element's description. Unlike *Label* it can be omitted. It is used to **provide *additional* information**. + > Note: If stated, *Label* and *Value* are **separated by a comma** in speech — **VoiceOver** will put a *pause* between them on its own. - > Note: Label and Value separates by comma automatically, it produced short pause between them - - > Tip: You can add additional commas in label or value, pronunciation will use them for short pauses + > Tip: But everything that happens inside the properties in terms of **pronunciation** is *our* responsibility. **Don't forget to use *punctuation marks* to help VoiceOver read texts *easier* for humans to listen to**. } @Column { - **Examples:** - - *1.4 billions views* – no value for regular text is ofter situation - - *Never Gonna Give You Up, **Rick Astley*** - - *Next, **Childish Gambino – Redbone*** – can add detalization about next track. Visually you can see a cover of the song, but for VoiceOver it is better to provide text alternative. Different approaches, but same experience. - - *Pizza Pepperoni, **Pepperoni, Mozzarella*** - - *Size, **Medium*** + **Same examples:** + - *1.4 billions views* does not have any additional information so no value. Label is enough. + - *Never Gonna Give You Up* may have a lot of additional information: the author, the album, the year and so on. + - *Next* may have a spoiler of what is next in its Value. For example, if this button is a part of an audioplayer functionality, visually it may have the cover of the next song, but adapted version will have the next song's name. + - *Pizza Pepperoni* may contain lots of data due to its cell nature. Price, ingredients, size, detailed description, availability and so on. + - *Size* will defenitely have a value of which size is selected at the moment. + - *Brightness*, just as *Size*, will have its current level as its value. } } -### Label vs Value +### Label vs Value: What's The Difference? + +It is important to **clearly differentiate *Label* and *Value* in order to properly *adapt* the element for various Accessibility Features**. -Important to understand differences between label and value. Label should be as short as possible: Voice Control will use it as HUD over UI to name things for feature voice commands, but not show value part, because we expect that it's already presented for user on screen. +For example, *Label* should be **as short as possible** for **Voice Control**: it will be used as a HUD over the UI to use the feature's *voice commands* and **there is no reason to *double* any other information already available on the screen**. -Otherwise, adjustable elements allow to change only value part and after change only value part will be pronounced to user. +Another example is **Adjustable Elements**: this feature will change *only* the *Value* part, so if you want to use it you have to **have everything changable outside the *Label* property**. -## Trait +## accessibilityTraits — Traits @Row { @Column(size: 2) { ``Book/accessibilityTraits`` - The last part of element's description is trait. Some traits may add additional text to element's description, other just changes behaviour. + `accessibilityTraits` is another *optional* property of the element's decription. *Traits* are used to **point at the element's *type*** — **depending on the type the feature's *behavior* may change**. - An element can have no trait - regular text, for e.g. + If there is *no* trait specified it would mean that the element is of a **regular text** type. - The most common trait is ``UIAccessibilityTraits_/button`` – it helps user to understand that he can interact with an element. + The *most* common trait that you're going to work with is ``UIAccessibilityTraits_/button`` — it's presence is a sign of an *interactive element*. + **If there is a *button* in the interface but it is not specified in its description — users *won't* be able to interact with this element using Accessibility Features**. - > Note: Label and Value are separated by comma, but trait represents another sentence and separated by dot automatically. - - > Important: Label and Value are `String` properties, but Trait can be selected only from limited amount of variants. - > - > Not duplicate trait's textual description inside Label or Value, because different technologies uses trait in different manear, not only for textual description. + > Note: If *Label* and *Value* are separated by a *comma*, *Trait* is separated from the other parts of the description by a *full stop*. + > Important: *Label* and *Value* are `String` properties, meanwhile *Trait* is **selected from a *limited* amount of options**. + > Important: **Don't mention *Trait* inside *Label* or *Value***. There is **no need to *double up* such facts for users: if the element is, for example, a *button*, they will know *everything* they need to know** depending on the **Accessible Feature** used. } @Column { @@ -97,21 +107,19 @@ Otherwise, adjustable elements allow to change only value part and after change **Samples:** -## Hint +## `accessibilityHint` — Hint ``Book/accessibilityHint`` -Provides additional information about element, usually how it should be called. Example: *tap twice to activate*. - -Unfortunately, every default button has a repetitive hint and almost all users of VoiceOver disables hints. As a result you can expect that only few users will see your customized hint. +**Hint** is another *optional* property that is used to **provide additional information about the element itself**. Property's *name* points at that: **we give a *hint* to the user about how to *treat* the element**. For example, «*tap twice to activate*». -Probably, some users will enable hints via when they use a new app and expect great accessibility adaptation. +> Important: Every *default* button has a *repetitve* Hint and such behavior results in that **majority of VoiceOver users disable that**, so you can't expect that many people will see your *customised* Hint. Though there is always a chance that curious users will turn them on for a new app while using : **to see how well the application is *adapted***. @Comment { // TODO: Describe hint } -## Full formula -@Image(source: "TraitsOrder", alt: "Reading order is controlled by designer") +## Full Formula +@Image(source: "TraitsOrder", alt: "Full formula of an adapted element") > Note: Container prefix is described in @@ -132,6 +140,6 @@ Traits that add additional text: - ``UIAccessibilityTraits_/searchField`` - ``UIAccessibilityTraits_/image`` -Other traits can add text to diferent place in description +Other traits can add text to different place in description - ``UIAccessibilityTraits_/selected`` - ``UIAccessibilityTraits_/notEnabled`` diff --git a/Sources/AccessibilityDocumentation/Documentation.docc/Articles/2. Advanced/AdjustableElements.md b/Sources/AccessibilityDocumentation/Documentation.docc/Articles/2. Advanced/AdjustableElements.md index eda054f..9b8046d 100644 --- a/Sources/AccessibilityDocumentation/Documentation.docc/Articles/2. Advanced/AdjustableElements.md +++ b/Sources/AccessibilityDocumentation/Documentation.docc/Articles/2. Advanced/AdjustableElements.md @@ -1,4 +1,4 @@ -# Adjustable elements +# Adjustable Elements Simplifies interactions with complex elements for VoiceOver. diff --git a/Sources/AccessibilityDocumentation/Documentation.docc/Resources/AdoptingCell/DescribeCell_3_2.swift b/Sources/AccessibilityDocumentation/Documentation.docc/Resources/AdoptingCell/DescribeCell_3_2.swift index 2a25408..6ff9740 100644 --- a/Sources/AccessibilityDocumentation/Documentation.docc/Resources/AdoptingCell/DescribeCell_3_2.swift +++ b/Sources/AccessibilityDocumentation/Documentation.docc/Resources/AdoptingCell/DescribeCell_3_2.swift @@ -3,7 +3,7 @@ Pizza sauce... from AED 30 Meat King Supreme Pizza sauce... -from AED 30 // Is it relates... +from AED 30 // Does it relate... Hawaii // To this title? Pizza sauce... from AED 30 diff --git a/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/1. Basic/AdaptingCell.tutorial b/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/1. Basic/AdaptingCell.tutorial index 14b9510..545c2e3 100644 --- a/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/1. Basic/AdaptingCell.tutorial +++ b/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/1. Basic/AdaptingCell.tutorial @@ -1,95 +1,103 @@ @Tutorial(time: 10) { @Intro(title: "Adapting Cell") { - To have assistive technology work as intented sometimes it is needed to **simplify complex cells** to such degree so there is no difference for accessibility features between *differentiated abstractions* that are stored in the cell. In other words, if there is a cell with pizza's description it is understandable to distinguish data by its nature: have an image as an illustration, a title, a list of ingridients and a price - but it complicates the work for VoiceOver, Voice Control and Switch Control. Such layout makes it adapt the cell's contents **wrong**. Let's take a look of what can be done to help our digital assistants navigate through the cognitive models we come up with,. + To have *assistive technology* work as intented sometimes it is needed to **simplify complex cells** to such degree so there is no difference for accessibility features between *differentiated abstractions* that are stored in cells. + + In other words, if there is a cell with pizza's description it is reasonable to distinguish data by its nature: have an image as an illustration, a title, a list of ingridients and a price - but it complicates the work for VoiceOver, Voice Control and Switch Control. + + Such detailed layout makes automated adaption of the cell's contents **wrong**. + + Let's take a look of **what can be done to help our digital assistants navigate through the cognitive models we come up with**. } - @Section(title: "The point") { + @Section(title: "What Is Wrong With The «Normal» Layout") { @ContentAndMedia { - Even though the cell looks simple such layout would lead to several *accessibility issues*. + Even though the cell looks simple it is not enough — such layout would lead to several *accessibility issues*. Let's see **how exactly different assistive technology *struggle* with that**. - @Image(source: "Chicken BBQ", alt: "Cell of Chicken BBQ with image, title, ingredients and price") + @Image(source: "Chicken BBQ", alt: "Cell of Chicken BBQ containing an image, a title, ingredients and a price.") } @Steps { @Step { - Why it is problematic for VoiceOver to adapt such interface? - - The thing is that **the focus works such way so it outlines *every* single element of a cell**. + Firstly, **there is a definite problem for *VoiceOver* to adapt such interfaces**. - Pay attention that **images are hidden from VoiceOver *by default***, therefore are *inaccessible* to be focused on. + The thing is that **the focus works such way so it outlines *every* single element of a cell starting from *the title***. + + > Note: Pay attention that **images are hidden from VoiceOver *by default***, therefore are *inaccessible* to be focused on. - The first thing put into the focus is **the title**. - - @Image(source: "DescribeCell_1", alt: "Focus outlines title") + @Image(source: "DescribeCell_1", alt: "Focus outlines the title of the cell first.") } @Step { - After a swipe to the right the focus moves to **the list of the ingredients**. + After a swipe to the right (which triggers **moving to the next element**) the focus moves to **the list of ingredients**. - @Image(source: "DescribeCell_2", alt: "Focus outlines ingredients") + @Image(source: "DescribeCell_2", alt: "In our case, secondly the focus outlines the ingredients' list.") } @Step { - Same way the next swipe will move the focus to **the price button**. + Same way the consequent swipe will move the focus to **the price button**. - > Note: The *only* possibility **for a user to understand that this element is interactive by hearing VoiceOver say that's it's a *button***. It can be made possible by specifying its `.button` trait. + > Note: The *only* possibility **for a user to understand that this element is interactive by hearing VoiceOver say that's it's a *button***. It can be made possible by **specifying its `.button` *trait***. - @Image(source: "DescribeCell_3", alt: "Focus outlines button with price") + @Image(source: "DescribeCell_3", alt: "Consequently the focus outlines the button with the price.") } @Step { - In such case the number of the swipes needed to go through a single cell is three. This is *too* many. + Overall the number of the swipes needed to go through a single cell is three. This is way *too* many: never forget that we're talking about a list of pizzas and **each pizza is an *independent* cell**. - @Code(name: "Several cells and wrong rhyme", file: "DescribeCell_3_0.swift") + @Code(name: "Several Cells, Wrong Rhyme", file: "DescribeCell_3_0.swift") } @Step { Moreover such discretion leads to a decrease in *comrehensibility*: users can easily **lose track of what pizza in particular they are going through at the moment**. - @Code(name: "Several cells and wrong rhyme", file: "DescribeCell_3_1.swift") { - @Image(source: "DescribeCell_3_3", alt: "Focus outlines button with price") + @Code(name: "Several Cells, Wrong Rhyme", file: "DescribeCell_3_1.swift") { + @Image(source: "DescribeCell_3_3", alt: "Focus outlines the button with the price.") } } @Step { - For example, *the price button* may be percieved connected to the next title. + For example, **the price button* may be percieved connected to the next title** which is something we really don't want to have. Normally prices are playing a critical role in choice-making. - @Code(name: "Several cells and wrong rhyme", file: "DescribeCell_3_2.swift") { - @Image(source: "DescribeCell_3_3", alt: "Focus outlines button with price") + @Code(name: "Several Cells, Wrong Rhyme", file: "DescribeCell_3_2.swift") { + @Image(source: "DescribeCell_3_3", alt: "Focus outlines the button with the price.") } } @Step { - Voice Control and Switch Control experience same problems too. They prioritise *interactive buttons* and as a result **the only label shown will be the price button's *label***. To press the whole cell users would have to, for example, pronounce *«Tap From AED thirty»*. + Talking about *price buttons*, there are ***Voice Control* and *Switch Control* that prioritise *interactive buttons*** and thus *struggle* with such layout too. As a result of their adapting behaviour **the only label shown will be the price button's *label***. To press the whole cell users would have to, for example, pronounce *«Tap From AED thirty»* — which is a nonsense. > Tip: The solution here is to **use *the title* as the cell's *label***. - @Image(source: "DescribeCell_4", alt: "Voice Control show badge over button with price") + @Image(source: "DescribeCell_4", alt: "Voice Control shows the badge over the button with the price") } } } - @Section(title: "Describe cell") { + @Section(title: "What Can Be Done: Cell's Description") { @ContentAndMedia { - In order to **properly describe the cell for VoiceOver** we have to transfer the text from *labels* to the *accessibility description* of the cell in a correct order and with a correct type. Let's take a closer look. + *VoiceOver's adaption* is all about **telling the user what's happening on the screen**. + + In order to **properly *describe* the cell so VoiceOver can read it correctly** we have to transfer the text from *labels* to the *accessibility description* of the cell in a *correct order* and with a *correct type*. Let's try to do so. - @Image(source: "DescribeCell_9_preview", alt: "Reading order is controlled by designer") + @Image(source: "DescribeCell_9_preview", alt: "Order in which elements are read is controlled by designers' vision.") } @Steps { @Step { - We will start with a simple cell with an explicit ViewModel. + We will start with a simple cell with an *explicit* `ViewModel`. @Code(name: "Cell and VoiceOver.swift", file: "DescribeCell_6.swift") } @Step { - First of all we *specify that the cell will be a *focusable element***. By doing that we *reduce* the number of elements available on the screen. + First of all we have to **specify that the cell will be a *focusable element***. By doing that we ***reduce* the number of elements available on the screen**, which is, as you remember from the previous section, really helpful for *adaption*. + + There is no need to *explicitly* hide other elements - setting the cell with `accessibleElements` property is enough. - There is no need to *explicitly* hide other elements - setting the cell with `accessibleElements` property is enough. How exactly it works is described in in great detail. + To see **how it works *exactly*** take a look at where everything is explained in *greater* detail than we can afford in *tutorials*. @Comment { // TODO: why the cell's button is visible at pizza? @@ -110,79 +118,91 @@ @Step { - Also there is *the price* which is an essential part of such cells. + Not to forget there is also *the price* which is **an *essential* part of cells with a *product offer***. + + To adapt it *correctly* we need to follow the strategy controlled by *the cell's design* whose concept is to make users *notice* the product. + + Its **image is what *attracts the attention***, then **title is read and understood *loud and clear*** - it's on top and visually distinguished by a *bolder* font used. - To adapt it correctly we need follow the strategy controlled by the cell's design. Its **image is what *attracts the attention***, then **title is read and understood *loud and clear*** - it's on top and visually distinguished by a bolder font used. Furtherly the attention may be *interrupted* by a **bright coloured button**. **Ingredients are least prior** to the attention and this is in their nature: this elements is of an *informative matter*. + Furtherly the attention may be *interrupted* by a **bright coloured button**. + + **Ingredients are least prior** to the attention and this is in their nature: this elements is of an *informative matter*, therefore not about *attention attraction*. Logically **we place the price *after* the title**. Pay attention that **to keep label simple the price has to be put in the beginning of `accesibilityValue`**. @Code(name: "Cell and VoiceOver.swift", file: "DescribeCell_9.swift") { - @Image(source: "DescribeCell_9_preview", alt: "Reading order is controlled by designer") + @Image(source: "DescribeCell_9_preview", alt: "Reading order is controlled by people who want to sell this pizza to you.") } } @Step { - To conclude description **the interactive element has to have its `.button` trait specified*. + Everything is *described* and VoiceOver is happy, but *most importantly* we shouldn't forget to **mark the interactive element with `.button` trait*. + + After that *specifying* we are done and did great! @Code(name: "Cell and VoiceOver.swift", file: "DescribeCell_10.swift") } } } - @Section(title: "Simplify scroll") { + @Section(title: "What Can Be Done: Ease Scrolling") { @ContentAndMedia { - In VoiceOver the default **scrolling is implemented by a three-finger swipe** that leads to reading the number of the visible page, for example, *«4 out of 20*». + In VoiceOver the **default *scrolling* is implemented by a *three-finger swipe***. The gesture will announce where the user currectly is, i.e. VoiceOver will **read the number of the *visible* page**. For example, *«4 out of 20*». + + **Going through *tables* of cells functions *exactly* the same way**. For example, *«from 25 to 40 out of 120»* will be said during going over the rows. - **Going through tables of cells functions *exactly* the same way**. For example, *«from 25 to 40 out of 120»* will be said during going through the rows. + Seemingly there is not much we can do to **simplify the scrolling**, but in reality technologies win. People who are responsible of these inventions are indeed smart, aren't they? So: - Seemingly there is not much we can do to **simplify the scrolling**, but in reality there is a trick. **Providing description for visible area allows to use commands that increase the *precision* of actions desired to be done**. Like, for example, asking to read all titles of the products which will results in hearing *«Chicken BBQ, Meat King Supreme, Hawaii»*. + **Providing *description* for *visible* area allows to use *commands* that increase the *precision* of actions desired to be done**. Like, for example, *asking to read all titles* of the products which would result in hearing *«Chicken BBQ, Meat King Supreme, Hawaii»*. - @Image(source: "DescribeCell_11", alt: "Describe screen after scroll") + @Image(source: "DescribeCell_11", alt: "Describe the screen after a scroll.") } @Steps { @Step { - To implement such possibility let's start with `MenuViewController` extension. + To **implement *comfortable* user experience** regardless of the fact that the interface is *adapted*, let's start with `MenuViewController` extension. @Code(name: "Describe screen after scroll.swift", file: "DescribeCell_11_0.swift") } @Step { - To add *description* we use `UIScrollViewAccessibilityDelegate` that can be used by any `firstResponder`. + We will use `UIScrollViewAccessibilityDelegate` to **add *description* that can be used by any `firstResponder`**. @Code(name: "Describe screen after scroll.swift", file: "DescribeCell_11.swift") } @Step { - In simpler words our goal is **to provide description for *all* visible cells**. It can be done by starting with the obvious path. + Which means we will **provide description for *all* visible cells**. Sounds exhausting, but is it so in reality? Let's try and see. @Code(name: "Describe screen after scroll.swift", file: "DescribeCell_12.swift") } @Step { - Firstly we **convert *cells* to *models***. + To start we **convert *cells* to *models***. @Code(name: "Describe screen after scroll.swift", file: "DescribeCell_13.swift") } @Step { - Secondly **the *titles* are extracted**. + From models **the *titles* can be easily extracted** — we do so. @Code(name: "Describe screen after scroll.swift", file: "DescribeCell_14.swift") } @Step { - The titles are joined in *a single row*, separated by *commas*. + Once we get the titles we join them in *a single row*, separated by *commas*. @Code(name: "Describe screen after scroll.swift", file: "DescribeCell_15.swift") } @Step { - And, as a result, **three-finger swipe will cause the *titles* to be listed outloud**. + And, as a result, **three-finger swipe will cause the *titles* to be listed outloud**. + + We are happy, VoiceOver is happy, but, most importantly, the user would not have to do anything unnecessary to see what's available on the menu. Congratulations! - Additionally you can add some quantity expectation after everything described above is done. @Comment { - // TODO: михаил рубанов что ты делаешь. + // Additionally you can add some quantity expectation after everything described above is done. + // TODO: михаил рубанов что ты делаешь. что ты хочешь сказать строкой сверху. } @Code(name: "Describe screen after scroll.swift", file: "DescribeCell_16.swift") @@ -196,7 +216,7 @@ @Assessments { @MultipleChoice { - How should be prices located among other elements? + Choose the *most* fitting location for a *price* in a cell. @Image(source: "Chicken BBQ", alt: "Cell of Chicken BBQ with image, title, ingredients and price") @@ -207,7 +227,7 @@ ``` @Justification(reaction: "Try again!") { - **VoiceOver *doesn't* distinguish such pieces of data**, but **Voice Control *has to have* price as a part of the element's label** in order to use it correctly. + **VoiceOver *doesn't* distinguish such pieces of data**, but **Voice Control *has to have* price as a value element** in order to use it correctly (as a button). } } @@ -220,62 +240,62 @@ @Justification(reaction: "That's right!") { - Voice Control will have a simple label, VoiceOver reads the price before the ingredients (because it's more important). Good job! + Voice Control has a *simple label* it wants, VoiceOver reads the price *before* the ingredients just as it should. Good job! } } @Choice(isCorrect: false) { - ``` Label: Chicken BBQ, Value: pizza sauce, mushrooms..., from 30 AED ``` @Justification(reaction: "That's right!") { - Such case would be a wrong ordered showcase strategy. One has to know the price *before* the ingredients. + Almost there, but **such case would be a *wrong* ordered showcase strategy**. One has to know the price *before* the ingredients. Imagine having to listen to an endless list of mushrooms and only then be informed that it doesn't quite fit the budget. } } } @MultipleChoice { - How to scroll down a table using VoiceOver? + What is **the default gesture for scrolling through a table** with VoiceOver? @Choice(isCorrect: false) { A regular swipe @Justification(reaction: "Try again!") { - Nope, vertical swipes are used for *adjustable elements* and other operations. Swipe from the bottom will close the current application, the one from the top will open Notifications Screen or Control Center. + Nope, ***vertical swipes* are used for *adjustable elements* and other operations**. + + For example, **swipe from the *bottom* will close the current application**, the one **from the *top* will open Notifications Screen or Control Center**. } } @Choice(isCorrect: false) { - Two-finger swipe + Two-fingers swipe - @Justification(reaction: "That's right!") { - Two-finger swipe up describes the entire screen *from the top*. - Two-finger swipe down describes the entire screen *from the selected item*. + @Justification(reaction: "Try again!") { + **Two-finger swipe *up* describes the entire screen *from the top***. + **Two-finger swipe *down* describes the entire screen *from the selected item***. } } @Choice(isCorrect: true) { - Three-finger swipe + Three-fingers swipe @Justification(reaction: "That's right!") { - @Comment { - / / миш че за хуйня - } - It's too long to wait for the price when you listen VoiceOver + Yep, this is it! + + If adapted *correctly*, the user will hear what is in the table without unnecessery for the moment information specified. } } @Choice(isCorrect: false) { - Four finger swipe + Four-fingers swipe - @Justification(reaction: "That's right!") { - Horizontal four-finger swipe switches beetwen applications. + @Justification(reaction: "Try again!") { + Unfortunately, this is not the answer. Horizontal **four-fingers swipe switches beetwen applications opened**. } } } diff --git a/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/2. Advanced/AdjustableTutorial.tutorial b/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/2. Advanced/AdjustableElements.tutorial similarity index 100% rename from Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/2. Advanced/AdjustableTutorial.tutorial rename to Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/2. Advanced/AdjustableElements.tutorial diff --git a/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/Tutorial Table of Contents.tutorial b/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/Tutorial Table of Contents.tutorial index 2d51472..85c65a7 100644 --- a/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/Tutorial Table of Contents.tutorial +++ b/Sources/AccessibilityDocumentation/Documentation.docc/Tutorials/Tutorial Table of Contents.tutorial @@ -1,13 +1,13 @@ -@Tutorials(name: "How To Adapt Your application") { +@Tutorials(name: "How To Adapt an iOS Application") { @Intro(title: "Just A Few Steps") { - To make an application accessible for the assistive technology and therefore allow people with Accessibility Features enabled comfortably use it one doesn't have to do much. The adaptation plan is as simple as: + To make an application *accessible* for the *assistive technology* and therefore *allow* people with Accessibility Features enabled comfortably use it one doesn't have to do much. The *adaptation plan* is as simple as: - 1. Simplify and group elements in UI's hierarchy - 2. Add labels to elements - 3. Add additional properties + 1. *Simplify* and *group* elements in the UI's hierarchy + 2. Add *labels* to elements + 3. Specify additional *properties* - Yep, that's it. In other words the adaption process is consisted of an optional reconstructing of already-existing elements' order and their description with some flags explicitly specified. + Yep, that's it. In other words **the adaption process is consisted of an optional *reconstructing* of already-existing elements' *order* and their *description* with some *properties* being *explicitly specified***. } @@ -31,7 +31,7 @@ } } - @Volume(name: "Climbing higher") { + @Volume(name: "Climbing Higher") { @Chapter(name: "Adjustable Elements") { Simplifies navigation and control over a complex element for VoiceOver @@ -52,23 +52,4 @@ @Comment { // TODO: Update links } - - @Resources { - Explore more resources for learning about sloths. - - - @Videos(destination: "https://www.example.com/sloth-videos/") { - Watch cute videos of sloths climbing, eating, and sleeping. - - - - [Treetop Breakfast](https://www.example.com/sloth-videos/breakfast/) - - [Slow Ascent](https://www.example.com/sloth-videos/climb/) - - [Rest Time](https://www.example.com/sloth-videos/snoozing/) - } - - - @Downloads(destination: "https://www.example.com/images/sloth-wallpaper/") { - Download the cutest sloth wallpaper for your iPhone, iPad, or Mac. - } - } }