Edit the Blog Post Header component above this, then place your content here, then fill out the Related Articles section below, if possible. You should have at least one related article and ideally, all three.
Feel free to add supplementary content to the sidebar at right, but please retain the Twitter component (it can live at the bottom of your added content).
This text component can be edited or deleted as necessary.
Related article title here
Related articles only have an image (the squarer version of the banner) and a title. This text can be deleted. Place 1-3 related articles.
[Part 1] Designing for everyone: A guide to accessibility on Amazon Fire devices
Fire OS powers a wide range of devices, from handheld tablets to big-screen TVs. Your app might be in the hands of a range of different users—from a hearing impaired child streaming a cartoon to a grandparent reading with a magnifier. As an app developer, you want to ensure your app works for everyone, regardless of their ability or how they interact with technology.
That's why you need to design with accessibility in mind. Accessible design substantially improves navigability and inclusivity. But along the way, it often leads to cleaner interfaces and more maintainable code too.
Let’s get into some key features, along with tips and strategies for building inclusive Fire apps.
Fire devices span a range of screen sizes and input types. At one end, you have touch-based Fire tablets. On the other end, you have voice- and remote-controlled Fire TVs. As a developer building for such a broad range, proper planning for these different interactions is essential.
Both Fire tablets and Fire TV support VoiceView (screen reader) and the Screen Magnifier. Fire tablets also offer Voice Access navigation, Eye Gaze, and braille display support. Fire TV devices offer closed captions, Text Banner for the visually impaired, and VoiceView Navigation.
Amazon provides accessibility guides for Fire tablets and Fire TV to help you with implementation. Beyond the code, however, you’ll need to understand how these accessibility tools shape the user experience. A layout that works great for touch may not work well for D-pad navigation. And depending on the task, a single user might switch back and forth between voice and magnification.
Fire tablets and Fire TV devices share some core accessibility features—like VoiceView and Screen Magnifier—but how those features are presented and used can be very different. Fire tablets generally offer more support for personal interaction, while Fire TVs emphasize remote-friendly and shared-use accessibility features. Designing for both means understanding these strengths—and avoiding assumptions that features behave identically across devices.
How do these various accessibility features line up across device types? Take a look at this table to see which features are supported on each platform.
Accessibility Feature |
Fire tablet |
Fire TV |
VoiceView Screen Reader |
||
Screen Magnifier |
||
Font Size Control |
Not available |
|
High Contrast Text |
||
Color Correction |
Not available |
|
Color Inversion |
Not available |
|
Closed Captions |
||
Audio Descriptions |
||
Stereo to Mono Audio |
Not available |
|
Switch Access |
Not available |
|
Navigation by Voice |
Limited (through Alexa) |
|
Remote Button Announcements |
Not applicable |
|
Text Banner |
Not available |
|
Hearing Aid Support |
Limited (through Bluetooth) |
|
User Profiles |
Not applicable |
Yes (personalized accessibility settings) |
Reading Aids |
Yes (Word Wise, Reading Ruler) |
Not available |
Eye Gaze Support |
Not available |
Building accessible apps for Fire OS means more than just supporting individual features in isolation. More importantly, you'll want to focus on how your app works across real-world scenarios.
- Design for different screens and inputs
- Fire tablets rely on touch. Fire TV devices rely on remotes and voice. Keep these user-input preferences in mind. For example, avoid small touch targets that are hard to hit. Make sure your TV UI has clear focus indicators for navigation.
- If it's important, label it
- If you’re using images, icons, or custom controls, then they need to have meaningful content descriptions. VoiceView won't be able to guess what a gear icon does; you have to tell it.
- Don’t assume users can see or hear everything
- Follow this basic principle: If you can see it, you should hear it. If you can hear it, you should see it. Use captions for audio. Announce dynamic text changes. Make sure alerts and errors are noticeable for VoiceView or Screen Magnifier users. Provide redundant cues, like color plus text plus sound. These will go a long way.
- Make text readable and layouts scalable
- Use scale-independent pixels (sp) for font sizes and density-independent pixels (dp) for layout spacing. That way, everything scales properly with system-wide font or zoom settings.
- Support alternate navigation methods
- Accessibility tools include Switch Access, voice commands, external keyboards, and braille displays. And your users might rely on any of these. Don’t block them with gestures or designs that only work one way.
- Keep the experience consistent and forgiving
- Users with cognitive differences benefit from predictable layouts and generous timeouts. Avoid surprises and provide clear feedback. Give your users more control by making it easy to back out or try again.
As your understanding of these principles deepens, your designs will evolve from accessibility-friendly intentions to real-world inclusive behavior. That's huge. But what does this look like in code? Here’s an example of how to implement one feature:
Supporting magnification and scalable layouts
When users with low vision access digital content, they depend on screen magnification. But when content is magnified, users see only a small portion of the screen at a time. That makes it easy to miss content that appears outside their current viewport. Additionally, when users increase system font sizes, layouts that aren't built with scalability in mind can break; text will be cut off or elements will overlap.
Imagine an input form where an error message appears when validation fails. Or a profile page where the text needs to scale with the user's font size preferences. To support screen-magnifier users effectively, you need to implement both content visibility management and scalable layout design.
To ensure dynamic content is visible to magnifier users, automatically bring new content into the user's magnified viewport when it appears on screen.
submitButton.setOnClickListener {
if (emailInput.text.isEmpty()) {
errorMessage.visibility = View.VISIBLE
// When a user is zoomed in, a new view appearing on screen might be
// outside their current magnified viewport.
//
// requestRectangleOnScreen() tells the system to scroll the view to
// ensure the specified rectangle (in this case, the entire
// errorMessage view) is brought into view.
val rect = Rect()
errorMessage.getHitRect(rect)
errorMessage.requestRectangleOnScreen(rect, false)
} else {
errorMessage.visibility = View.GONE
}
}
The important method here is requestRectangleOnScreen(rect, false), which ensures that when an error message appears, it's automatically brought into the user's current magnified viewport. This helps prevent them from missing important information.
To ensure proper scaling across different devices and user preferences, choose the right units. For example:
<TextView
android:id="@+id/user_name"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:text="Username Example"
android:textSize="20sp"
android:layout_marginStart="16dp"
app:layout_constraintStart_toEndOf="@id/profile_icon"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintTop_toTopOf="@id/profile_icon" />
The key details in this example are:
● sp for text sizes, which respects user's system font size preference
● dp for margins and padding, which scales consistently across screen densities
● 0dp width with constraints, which allows views to expand or contract as needed
Finally, use ConstraintLayout to create relationships between views that adapt to content changes. For example:
<TextView
android:id="@+id/user_bio"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:text="This is a sample bio that will wrap to multiple lines and demonstrate how using scalable units (sp) allows the text to grow without breaking the layout."
android:textSize="16sp"
android:layout_marginTop="8dp"
app:layout_constraintStart_toStartOf="@id/user_name"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintTop_toBottomOf="@id/user_name" />
The constraint relationships (specified with layout_constraint*) ensure that when text grows or shrinks, the layout adapts without clipping or overlapping content.
When implementing these measures, remember to test your layouts with:
- Screen magnification enabled at various zoom levels
- Large font sizes in system settings
- Different screen densities and orientations
Consider implementing support for these other accessibility features as well:
- Closed captions and subtitle customization
- Voice control via Alexa (especially for Fire TV)
- Compatibility with Voice Access navigation, Speak Selection, Switch Access, braille displays, and external keyboards
- VoiceView, a key feature of Fire OS devices, that enables visually impaired users to navigate the Fire TV user interface. Another article dedicated to just VoiceView is coming soon.
During development, test your accessibility features on real Fire tablets and Fire TV devices. Test with VoiceView, Screen Magnifier, and Switch Access. Most importantly, get feedback from users who rely on these features—real-world testing is your best validator.
Accessibility cannot be a bonus feature or an afterthought. It's a must-have that makes your app usable for all your users—users of all backgrounds, abilities, and expectations. When you design with this full range of users in mind, you build software that's more inclusive. But you also end up with an app that's more polished and intuitive for everyone.
Whether you’re updating an existing Fire app or building a new one, you can start small if you need to. Label icons. Test with VoiceView. Try navigating your UI with a remote instead of a finger. Each step improves the experience for someone—and usually, for many.
Supported devices
© 2010-2025, Amazon.com, Inc. or its affiliates. All Rights Reserved.