Book Dragon Accessibility
Accessibility matters to me personally because I am legally blind. I use accessibility technology every day, and I know how quickly an application can become frustrating or unusable when accessibility is treated as something to add at the end. Book Dragon Archive was built with accessibility in mind from the beginning, but I also want to be careful about what that means. I am one disabled programmer building an application that I want to be inclusive for as many people as possible, and my experience with blindness does not give me firsthand understanding of every disability, every assistive technology, or every way someone may need to interact with the app.
My goal is to keep improving Book Dragon Archive as I learn where those needs are. Version 1 will not represent the end of that work, and there may be accessibility goals that are incomplete when the first public release arrives. If you use Book Dragon with a disability and encounter something that makes the app difficult or impossible to use, I want to hear about it. If there is a change I can reasonably make within Book Dragon that would remove that barrier, I would rather know about it so it can become part of the development process. You can reach me directly at
Accessibility in the Current App
Book Dragon Archive is built with SwiftUI and uses native iOS controls for much of its navigation, forms, buttons, lists, and selection interfaces. Many important controls and pieces of information include VoiceOver labels, hints, values, or accessibility grouping, while decorative artwork is removed from the accessibility tree when nearby text already communicates the same information. Most interface text uses semantic system text styles so it can respond to the text-size settings built into iOS, and key workflows are exercised in automated testing at Accessibility XXXL to look for clipping and other layout problems.
The app also responds to Reduce Motion in the places where Book Dragon currently uses intentional animation, including scanner reset behavior and automatic scrolling during voice confirmation. Book entry is not dependent on using the camera, so identifiers and book information can be entered manually, and the scanner provides alternatives when camera access or automatic page detection is unavailable. The optional voice-request workflow also includes an editable transcript before the request is interpreted, while normal text entry remains available.
Accessibility testing has already found problems that changed the application. Automated audits have exposed issues such as low-contrast text, interface elements that did not scale properly with large text, overflowing controls, and interaction targets that were too small on iPad, and those problems were corrected rather than treated as acceptable side effects of the design. The current automated test coverage includes selected inventory, book-detail, series, manual-entry, voice, duplicate-handling, barcode, iPhone, and iPad workflows.
What We Are Still Testing
Automated accessibility testing is useful, but it is not the same thing as putting the application in the hands of someone who depends on an assistive technology. Book Dragon's current validation plan still calls for physical-device testing with VoiceOver, every accessibility Dynamic Type category, Increased Contrast, Button Shapes, Reduce Motion, representative iPhone and iPad orientations, and the physical camera scanner with its manual-entry fallback.
Because that work is still continuing, I do not want to claim that every screen has been fully audited, that every accessibility setting will work perfectly in every workflow, or that Book Dragon Archive has been certified as conforming to a particular accessibility standard. The project materials do not establish that kind of certification, and selected automated simulator checks are not enough to make the claim honestly. Some compact visual elements also still use fixed-size styling, so successful testing at large text sizes in key workflows should not be interpreted as proof that every screen will behave perfectly at every setting.
Accessibility Should Not Depend on One Disability
My own experience naturally makes blindness and low vision easier for me to notice because those are barriers I encounter myself. That does not mean accessibility begins and ends with VoiceOver, larger text, contrast, or camera alternatives. Someone with limited dexterity, hearing loss, cognitive disabilities, motion sensitivity, or another disability may encounter a problem I never would have known to look for.
That is one of the reasons I do not want to treat accessibility as a checklist that eventually becomes complete. A test can tell me that a button has a label, a sufficient hit area, or an acceptable contrast value, but it cannot tell me every way a real person may struggle to complete the task that button belongs to. The only way Book Dragon gets better at those problems is if the people who encounter them are able to tell me where the app is failing them.
Tell Me What Is Missing
If Book Dragon Archive creates an accessibility barrier for you, please send a message to
I cannot promise that every requested change will be simple, immediate, or technically possible, especially as a single developer, but I can promise that accessibility problems will be treated as product problems rather than edge cases. Book Dragon Archive is supposed to help people manage the books they care about. If the design prevents someone from doing that because of a disability, then there is still work to do.