How can you include accessibility in your app?

Think about accessibility before the build even begins 

Have you ever seen a building that had a wheelchair ramp added as an afterthought? Think of an all green building with a random red ramp. It looks messy and forced, right? It looks like it’s not supposed to be a part of the building. Adding in accessibility to your app after you’ve finished has the same look to it. So how do you avoid that? 

The best way is to consider the accessibility aspects of your app before you start. This means that accessibility for as many users as possible must be a forethought when creating your app. Ways to make it easier for all people to use your application have to be thought about before the building process even begins and definitely not after. Considering all types of users in your design will allow for a smoother design process and a better-looking design.

Avoid bad design at all costs.

Including accessibility in your application is the right choice, but it needs to be done correctly. Here’s a little secret: people don’t like bad design. Bad design is painfully noticeable. And bad design is usually what happens when accessibility isn’t thought about until after the application is already built (it’s also a way to build up some nasty design debt). Avoid it at all costs by simply including accessibility in the planning process because people will notice. Accessibility doesn’t have to be clunky and awkward. Good design is seamless and accessible technology should be, too.

For the basics on getting started with accessible design, check out Learn the Basics of Accessible Design. 

Understand that accessibility is not one size fits all.

There are a few concepts to consider when planning for accessibility technology. Accessible technologies work across a wide range of differing abilities and work to accommodate as many people as possible. That means it needs to be thought about every step of the way, from text size to application colors. 

Give users the option to enlarge text. This will make your app easier to use for all people, especially for blind or visually impaired individuals. Additionally, a voice-to-text option is very helpful for those who are deaf or hard of hearing but will also benefit a person on the go. Captions are beneficial for those who struggle with hearing but also make for a more enjoyable viewing experience for all people. 

Why is Accessibility so important? 

Accessibility means opening your app to as many people as possible.

So now you know that accessibility means making your application available to as many people as possible. But maybe you still need more convincing on why you should include accessibility in your app. Not a problem. 

For starters, consider that accessibility is a critical aspect of universal design. Universal design is the design of products and environments to be usable by all people to the greatest extent possible without adaptations and special design.  The fact of the matter is that 1 in 4 Americans has a disability. So, including accessibility is not just the right thing to do, but it also opens you up to a whole new customer base. 

Accessibility makes for a great customer experience.

The beauty of accessibility is that each user can interact with your application in the way that works best for them. Remember, first impressions are everything. Once users click out of your application, you want to make sure you did everything in your power to ensure they come back. How do you get users to keep coming back to your application? Great question. 

The answer is simple: excellent customer experience. Customers don’t want to feel frustrated when using your application, and by not including aspects that make for a great customer experience such as accessibility, many customers will be left feeling very disappointed when they cannot use your application correctly and are going to take their business elsewhere. Avoid losing customers by simply keeping customers happy. Keep customers happy by making your application user-friendly for all people.

There is literally money at stake 

Title II and Title III of the ADA requires that software, websites, and apps be accessible to as many people as possible. Not following those guidelines? That could end up literally costing your company money paid out in fines. 

Additionally, if your app leaves out an entire customer base or makes tasks more difficult for certain employees, you’re losing money, both from potential clients and from the time spent having to create workarounds. 

It’s the right thing to do

Bottom line – accessible technology is key for creating a more equitable society and that’s some good stuff for all of us. There’s also a really good chance that you’ll find that the more thoughtful you are about how you build your apps from an accessibility standpoint will translate to being more thoughtful about how you approach different parts of your business.  

Now that you have an understanding of why accessibility is essential and how to get started with accessibility in your app, you may be wondering how you can begin to implement it with actionable steps. Give us a shout and we’ll be happy to talk through all the ins and outs of what makes for a well-built app for everyone.                                                                                                                                                                                                                                 

Resources

https://sopa.tulane.edu/blog/why-accessible-technology-important

https://it.wisc.edu/learn/guides/accessible-content-tech/what-is-accessible-technology/

The post Why Accessibility in Tech is Vitally Important appeared first on Big Nerd Ranch.

What is Semantic HTML?

Semantic HTML is the use of HTML markup to relay the meaning of what is being displayed on the screen for the browser, and subsequently, an assistive technology, to interpret. In order to use the internet and digest content on web pages, individuals with visual impairments need to rely on screen readers such as JAWS, NVDA, and VoiceOver to navigate the web. All of these tools utilize an Accessibility API exposed by the browser to access something called the Accessibility Tree. The Accessibility Tree is derived directly from the DOM and provides semantic information for screen readers and other assistive technologies to consume. This is where semantic HTML comes into play. The browser can only populate the Accessibility Tree with the information provided to it through HTML markup written by the developer, you!

Using Non-Semantic HTML

To demonstrate how important semantic HTML is, let’s first look at some HTML that is not semantic, and take a peek at what the Accessibility Tree looks like.

<html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>My Website</title>
    </head>
    <body>
        <div class="header">
            <h1>My Website</h1>
            <div class="nav">
                <ul>
                    <li><a href="#">Home</a></li>
                    <li><a href="#">Blog</a></li>
                    <li><a href="#">About</a></li>
                </ul>
            </div>
        </div>
    
        <div class="main">
            <h1>Blog</h1>

            <div>
                <h2>Blog Post 1</h2>
                <img src="https://via.placeholder.com/150" />
                <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam. Duis aute irure dolor in reprehenderit.</p>
            </div>

            <div>
                <h2>Blog Post 2</h2>
                <img src="https://via.placeholder.com/150" />
                <p>Lorem ipsum dolor sit amet, consectetur adipisc irure dolor in culpa qui officia deserunt mollit anim id est laborum.</p>
            </div>
        </div>
    
        <div class="footer">
          <p>&copy; 2021 Big Nerd Ranch</p>
        </div>
    </body>
</html>

If you open up this HTML in a web browser, you will see a very simple, albeit ugly, website. Note that I added some very minor styling to arrange and separate items appropriately.

Taking a look at the Accessibility tab in the browser, you will see something like this (it may vary slightly between browsers):

As you can see, all of the content on the page is present within the tree. These are derived from the HTML elements in the DOM that contain information relevant to assistive technology. An HTML div is considered a non-semantic element. They are used to structure your webpage, but they do not tell the browser anything about the content they contain. Therefore they are excluded from the Accessibility Tree.

While this web page does look how we want it to look, the current HTML does not provide meaning, or semantics, for the browser to properly structure the Accessibility Tree. Instead, the browser structures it as a flat list of content. This does not allow someone using a screen reader to properly interpret what information is grouped together, or where they are on the page.

Let’s actually open up a screen reader of your choice to listen to what someone using these technologies would hear. When you have it open, use the arrow keys to go both forward and backward through the webpage. Try doing this with your eyes closed! You’ll probably notice, even on this simple page, it is very easy to get lost. You hear a lot of text being read to you, but there is no certainty where that text exists on the page.

Using Semantic HTML

Let’s try to clean up the HTML to provide more meaning to the structure of this website.

<html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>My Website</title>
    </head>
    <body>
        <header class="header">
            <h1>My Website</h1>
            <nav class="nav" aria-label="Main Navigation">
                <ul>
                    <li><a href="#">Home</a></li>
                    <li><a href="#">Blog</a></li>
                    <li><a href="#">About</a></li>
                </ul>
            </nav>
        </header>
    
        <main class="main">
            <h1>Blog</h1>

            <article>
                <h2>Blog Post 1</h2>
                <img src="https://via.placeholder.com/150" alt="Placeholder Image" />
                <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam. Duis aute irure dolor in reprehenderit.</p>
            </article>

            <article>
                <h2>Blog Post 2</h2>
                <img src="https://via.placeholder.com/150" alt="Placeholder Image" />
                <p>Lorem ipsum dolor sit amet, consectetur adipisc irure dolor in culpa qui officia deserunt mollit anim id est laborum.</p>
            </article>
        </main>
    
        <footer class="footer">
          <p>&copy; 2021 Big Nerd Ranch</p>
        </footer>
    </body>
</html>

If you load this updated HTML into the browser you will see, well, it looks exactly the same from a visual perspective. But take a look at the accessibility tab and you’ll notice with just these new semantic elements in place, the Accessibility Tree is now structured differently.

You can now see that the tree is split up into three elements: banner, main, and contentinfo. The semantic HTML that we wrote for our webpage has automatically given our browser what is called an ARIA role for each semantic element that structures the site. What do these ARIA roles tell an assistive technology?

• The banner element comes from our header and contains informative content about the website, and is typically located at the top of a webpage.
• The main element contains, as it indicates, the main content or topic of the webpage.
• The contentinfo element comes from the footer on our webpage and typically contains identifying information about a webpage such as copyright.

These are just a few of the many ARIA roles that are available. For a full list of ARIA roles, check out this page on MDN Web Docs.

If you click on the banner dropdown in the Accessibility tab, you will also see a heading and a navigation block. Taking a look back at our first non-semantic Accessibility Tree, you can see that the navigation items within our ul element is simply shown as a list. This would not tell someone using a screen reader that they are looking at navigation. We do not want to force a user to have to stop and try to figure out where the navigation is on the webpage. Using the nav HTML element will apply the ARIA role of “navigation” and allow a screen reader to convey this to the user.

Now open up the main element in the Accessibility Tree and you will see there is a heading and two article elements. An article is a section of the page that displays content that can be completely standalone content such as news articles and, as in our example, blog posts. This will allow someone using assistive technology, such as a screen reader, to differentiate the blog post from the rest of the content on the screen.

I’ve also added something called aria-label to the nav component. This gives a little bit more context about what the element contains. While on this simple webpage an additional label of “main navigation” may not be necessary, it is very common for a page to have more than one nav element in order to separate out the main navigation from other navigation on the current page. Without a label, a screen reader will read both navigation elements the same. Providing a label will remedy this, and give context that the user is on the main navigation for the website, and not a sub-navigation area.

Finally, I added a property to the img elements: alt. This should be on every img element that you use. A visually impaired individual may not be able to see the images on a web page. The alt text that you write should very briefly describe what the image is and will allow a screen reader to tell the user what is being shown in the image.

What I have demonstrated here is just scratching the surface of semantic HTML. While we only looked at a few of the available semantic HTML elements, you can clearly see how much they play an important role in providing all users with the best web experience possible. Sure, you can create a web page with anonymous HTML elements and have it look exactly how you want it to look. But in order to provide the structure and meaning behind what you see for assistive technologies to correctly interpret, building a website with semantic HTML provides the building blocks necessary.

The post The Importance of Semantic HTML for Web Accessibility appeared first on Big Nerd Ranch.

When it comes to auditing your app, there are a variety of tools and methods available to help. Generally, you’ll want to spend time getting familiar with accessibility features and navigating through your app as one of your users. Xcode also provides the Accessibility Inspector, which is a handy way to see what accessibility settings might be missing on User Interface (UI) elements.

Manually Auditing

It’s best to explore the different accessibility options on your iOS device before anything else. Getting familiar with how users navigate apps using assistive technologies is essential to understanding where you should improve your app.

VoiceOver

When thinking about accessibility, the first thing that comes to mind is VoiceOver. iOS does a decent job at making labels, buttons, and sometimes images accessible by default, but there is still room for improvement. To tell how accessible your app truly is, enable VoiceOver on your device and run through it as a user. It’s important to both note which elements are focusable (they’ll appear with a box around them when focused and be read aloud) and the overall flow of the focus. To get a full example of using the app as a user, it’s helpful to enable the screen curtain feature which will black out your screen while allowing you to use VoiceOver gestures. Once you have VoiceOver on, the easiest way to toggle screen-curtain is by using the three-finger triple-tap gesture.

Try experimenting with different VoiceOver rotor options to see how elements are focused. If you’re unfamiliar with the rotor, “Getting Familiar with iOS VoiceOver’s Rotor” will get you started.

Display & Text Size

VoiceOver isn’t the only accessibility feature you should explore. “Display & Text Size” is another prominent feature and might be even more widely used than VoiceOver. Some users may be able to see but have a difficult time with small fonts on their devices. In the iOS Accessibility settings, there is an option to increase text size significantly. However, UILabels do not handle this out of the box. To test different font sizes:

1. Navigate to Settings
2. Select “Display & Text Size”
3. Select “Larger Text”

Here you can change the text size with the slider at the bottom of the screen. To use even larger sizes, enable the “Larger Accessibility Sizes” toggle. Now the slider should show an even larger range of sizes.

Returning to your app, take note of which labels, if any, respond to this setting. It’s important to take note if text gets cut off, truncated, or appears incorrectly. Buttons should also scale and increase their text size per the settings. It may be an edge case, but be sure to check the largest size together with the “Bold Text” option (also on the “Display & Text Size” screen) to account for the largest option. Making your app look good and function at the largest size is a great way to ensure all sizes in between will likely work.

Tip: Try using “Smart Invert” to find items that aren’t inverting but should and vice-versa. The more you track down and fix, the more useful your app will be for accessibility users!

Voice Control

Voice Control is a handy feature that can also aid you in assessing accessibility. It assumes that users have sight and voice and can use their voice to navigate their device using commands like “Swipe left,” “Tap,” etc. There’s also an “Overlay” option where you can enable “Item Names” which provides a nice at-a-glance view of what accessibility sees.

Using Accessibility Inspector

Manually testing your app to see what is accessible is essential, but there are also tools available that can speed up your assessment by identifying the low-hanging fruit. The Accessibility Inspector can help you step through your app and scan all of the accessibility settings on UI elements for issues to fix. You can find the Accessibility Inspector in Developer Tools:

1. Open the “Xcode” menu in the menu bar
2. Select “Open Developer Tool”
3. Select “Accessibility Inspector”

In order to use the Accessibility Inspector to check your app, you’ll have to connect your device to your MacBook or launch your app in a simulator. Once it’s connected, it will show as an option in the device dropdown.

Once you’ve chosen the device or simulator, the Accessibility Inspector will show all of the basic settings, actions, element details, and UI element hierarchy. For the purposes of accessibility, we’re going to focus on the “Basic” section. In there, you can see the values set for the accessibilityLabel, accessibilityValue, accessibilityTraits, and the accessibilityIdentifier. By pressing the “Audio” button, you can also hear the label read aloud. Keep in mind that this isn’t always exactly what VoiceOver speaks on a device! For one thing, it does not voice or show the accessibilityHint.

There are multiple options available for navigating through the focusable elements in your app:

• Enable the Inspection Pointer which allows you to hover over simulator elements.
• Use the Next/Previous element buttons to manually move through elements in focus order.
• Press the Play button to automatically move through elements as VoiceOver finishes voicing each one.
•  You also have the option to navigate through the elements without any audio by toggling the audio button off.

By going through your app with the Accessibility Inspector, you can verify accessibility settings and perform a more in-depth audit of what is missing.

Inspector Audit

Last but not least, the Accessibility Inspector also has an audit feature! This goes through all of the UI elements on the screen and lets you know which ones may be inaccessible with VoiceOver. It also lets you know which elements don’t support Dynamic Text.

Simply switching to the audit screen and pressing “Run Audit” gives you a list of issues to fix. Above, you can see that the screen audited is missing accessibility settings on multiple UI elements, and its labels don’t allow dynamic sizing. The eye button next to each item will show you which UI element the warning is referring to. There is also a button with a question mark in a circle next to that which provides suggestions on how to fix the issue.

Fixing all of these warnings is a great start to making your app more accessible! As you fix issues, you can re-run the audit periodically to check what is left to fix. These tools are a great starting point, but it’s critical to also manually test your app as a user to verify things work as expected when using accessibility options.

Inspector Settings

You might have noticed that there’s a settings button available in the Accessibility Inspector as well. These settings allow you to make real-time adjustments to your app to test accessibility. For example, if you enable Dynamic Text on a label, using the font size slider will change the size of text on the simulator immediately.

Conclusion

Making your app accessible isn’t as daunting as it seems. With all of the tools available and some time to audit your app, you can identify significant usability improvements. Implementing these improvements is a huge win for your users and makes your app more user-friendly for everyone!

Ready to start implementing VoiceOver? “Implementing VoiceOver with a Custom Rotor” provides an example of how to integrate your app with VoiceOver’s rotor.

The post Auditing Your App for Accessibility appeared first on Big Nerd Ranch.

Getting Started

If you’re looking to add accessibility to an existing application the best way to get started is to perform an audit on the current app. There are many tools available to help with this process but for the purposes of this blog post, we’re going to lean towards a basic manual approach.

You can get a sense of how accessible your app is by enabling VoiceOver on your device and running through your application as a user. While you could wear a blindfold or close your eyes, you’ll probably want to use the screen curtain feature instead. When on, the screen is blacked out. Once you have VoiceOver on, the easiest way to toggle screen-curtain is by using the three-finger triple-tap gesture.

Take note of how the app reacts to different rotor navigation options, what it says when focusing on images, links, buttons, etc. Pay special attention to how and whether UI changes are announced: when a notification pops up or a long-running task completes is this communicated via VoiceOver?

With VoiceOver, you should be able to access all functional elements on the screen, and the focus order should be sequential. Keep an eye on that focus order: some UI elements might become focused out of order when using accessibility out of the box, and you might even inadvertently create a “focus trap,” where next/previous migration gets stuck in a small portion of the UI. These issues are generally easy to fix, and they’re a huge win for users!

Using Apple applications as a test is a great way to get familiar with some standards and how VoiceOver should flow before testing your own application.

Basics

To get started with VoiceOver accessibility implementation the best place to begin is by taking a look at the UIAccessibility documentation. Here you’ll find all of the settings available for your UI components. There are a lot of options there but some of the most commonly used ones are outlined below:

• accessibilityLabel – Text is spoken to the user when the element is focused.
• accessibilityHint – A description of what the element does. Hints can be enabled/disabled by the user in settings.
• isAccessibilityElement – Specifies whether or not this UI element is focusable.
• accessibilityTraits – Used to describe the UI elements usage, behavior, or state, e.g., isSelected, image, header, etc.
• accessibilityValue – The value of an element, e.g., progress on a slider or state of a toggle.

Implementation

Let’s work through an example starting with a simple rating app. The screenshot above shows a single-page application with a title, image, description, rating, and submit button. The idea here is that the user is able to rate the item shown in the picture. Out of the box, VoiceOver focuses on the labels and buttons which are read out loud and provide some context to the user, but not everything is focusable. As you can see, both the image and the rating control are skipped over completely.

Headings

The accessibility API provides traits that can be used on different UI elements. These let the user know additional details such as usage, behavior, or state. A UI element can have multiple traits associated with it. For example, let’s say you have a UISegmentedControl with multiple options. Since it is a button, it should have the button trait. The selected item should also have the selected trait. As a result, when the user focuses on the selected item, VoiceOver will announce it as both a “button” and “selected.”

Some of these accessibility traits are also used by the rotor to select different elements on the screen. If you’re unfamiliar with the rotor and how to use it, Getting Familiar with iOS VoiceOver’s Rotor provides a quick overview. With this example app, if you use the rotor to select “Headings” and then one-finger flick up and down, VoiceOver responds with, “Heading not found.” Even though the “Authentic Cowboy Hat” title is intended to be the heading for this screen, it’s not recognized as one, because the header trait is not set. To fix this, you can add a header accessibility trait on that label:

titleLabel.accessibilityTraits = [.header]

This marks the label as a header, which in turn allows the rotor to navigate to it when using the headings navigation setting. This setting also causes VoiceOver to announce “heading” after the content of the label.

Images

In this application we want the user to know what it is they are rating. Since the image is not purely decorative, VoiceOver should be able to focus on it and provide a description. If you simply enable VoiceOver on the image, iOS will do its best to describe the image to the user. You can make the image accessible by adding:

productImageView.isAccessibilityElement = true

Now if we run the application again and ask it to read the page from the top, the image proves focusable! Hint: try a two-finger swipe up while VoiceOver is active, which activates “Read from Top.”

Notice that when VoiceOver focuses on the image it says “image, cowboy hat.” The spoken “image” is from the accessibilityTrait for the UIImageView, and the “cowboy hat” is the system trying to describe the image contents to the user. In this case, the image is pretty clear, so it does a good job figuring out what it is. To meaningfully leave a rating, though, the user needs more details about the style of cowboy hat. The spoken text can be changed by adding an accessibilityLabel to the image:

productImageView.accessibilityLabel = "Dark brown leather hat with embellishments"

Custom Rotor

Last but not least, a VoiceOver user cannot interact with the star rating control on the screen. This is because it’s a UIStackView with a set of five UIImageViews. To make it even less accessible, the app is using a UITapGestureRecognizer to handle the user interaction with the stack. By default, UITapGestureRecognizers are not accessible and do not function when VoiceOver is turned on. While there are some instances where gesture recognizers can be used with VoiceOver, this particular implementation would benefit from a custom rotor.

UIStackViews aren’t focusable by default, so let’s begin by making it accessible:

ratingStackView.isAccessibilityElement = true

Now the element is selectable, but VoiceOver doesn’t say anything. It needs an accessibilityLabel that describes the current state. Assuming the currentRating variable contains the current star value, we can include that in the label:

// The rating goes from 0 to 4 but the user should hear 1 to 5
ratingStackView.accessibilityLabel = "Rating: (currentRating + 1) out of 5"

At this point, the user can’t really interact with the rating control besides focusing on it and hearing the current state. This is where we can add a custom rotor that allows the user to quickly flick up and down to change their rating of the item.

// The name of the rotor is the title in the rotor item selection and what the user hears
let ratingRotor = UIAccessibilityCustomRotor(name: "Rating Value") { [weak self] predicate -> UIAccessibilityCustomRotorItemResult? in
    guard let self = self else { return nil }

    // When the user flicks up we want to increase the rating and down is used to decrease while keeping it within bounds
    let isFlickUp = predicate.searchDirection == UIAccessibilityCustomRotor.Direction.previous
    let delta = isFlickUp ? +1 : -1
    rating = min(max(0, rating + delta), 4)

    // Handles the UI updates to fill in the stars
    self.setRating(value: rating)

    // Notifies the system that the layout for the rating stack view changed
    UIAccessibility.post(notification: .layoutChanged, argument: self.ratingStackView)

    return UIAccessibilityCustomRotorItemResult(targetElement: self.ratingStackView , targetRange: nil)
}

The code above creates a custom rotor that updates the rating up or down by 1 star with each flick up or down gesture respectively. The final step is to add this rotor to the element that we want it to work on:

ratingStackView.accessibilityCustomRotors = [ratingRotor]

At this point the ratingStackView has a custom rotor called “Rating Value”. When the user focuses on the ratingStackView, VoiceOver automatically says, “Use the rotor to access Rating Value.” This hint lets the user know that there is a rating value option available in the rotor.

The app now has a custom rotor! Custom rotors provide endless possibilities when making your app more accessible to VoiceOver users. All of your cool custom controls can easily be made accessible to everyone.

Conclusion

When stepping through the application with VoiceOver, the user can now interact with all of the items and perform the same functions as non-VoiceOver users!

This covers some of the basic settings and uses for VoiceOver functionality. VoiceOver is not just limited to the examples above but they provide a great starting point. Rather than adding accessibility to your app as an afterthought, adding it from the beginning of the app development process and designing with those users in mind makes a big impact on the usability of your implementation.

Suggested challenge: rotors are great for some applications, but this star control would also make sense treated as a slider. Update the code to use the adjustable trait and accessibility value instead of a custom rotor. Which do you find more usable?

Want to play around with the code? You can find the code from this post here.

The post Implementing VoiceOver with a Custom Rotor appeared first on Big Nerd Ranch.

Starting VoiceOver

Starting VoiceOver is easy.

1. Navigate to Settings
2. Select “Accessibility”
3. Select “VoiceOver”
4. Enable VoiceOver

Tip: The “VoiceOver Practice” page is a great way to try out gestures and see what they do!

Rotor Use Basics

The rotor is accessed by using a two-finger rotation gesture. To bring it up, ensure VoiceOver is enabled, then place two fingers slightly spread apart on the screen. Keep one finger as a pivot point and move the other finger around as if to draw a circle. You should see the dial appear and move between options as you rotate. Enabling an option is as simple as just stopping the gesture with that option selected. Once you have selected an option you can use an up or down one-finger flick gesture to adjust the option. For example, if you select “Speaking Rate” on the rotor then flick up, the rate of speech will increase. VoiceOver will speak and let you know the new rate with every flick up or down.

There are default options that come pre-set with the rotor including characters, words, lines, and speaking rate, but the rotor is not limited to just these options. If you head back to the same VoiceOver menu in Settings there is a rotor menu that allows you to select and reorder the rotor options you wish to use. There are a whole variety of additional navigation options and settings.

Rotor Navigation Example

Let’s go through an example of one of the navigation options:

1. Enable VoiceOver (Pro tip: ask Siri to “Turn on VoiceOver”)
2. Launch the Apple News App (ask Siri to “Open Apple News”)
3. Navigate to a news article
4. Using the two-finger rotation gesture, pull up the rotor and select “Words”

At this point, you’re set to navigate through the page contents word by word. When you flick down, the system will highlight each word and read it out loud.

There are a variety of different VoiceOver navigation options available in the rotor. You can navigate by characters, words, lines, containers, headings, links, images, and more.

Up Next

Now that you have an understanding of all of the different rotor settings it’s time to get familiar with VoiceOver implementation and make a custom rotor to take your app’s accessibility to the next level!

Further Reading

Apple’s “About the VoiceOver rotor on iPhone, iPad, and iPod touch” introduces the rotor and its capabilities.

The post Getting Familiar with iOS VoiceOver’s Rotor appeared first on Big Nerd Ranch.