Microsoft is doing some amazing things with regard to accessibility and innovation. They recently had a commercial air during the SuperBowl for their adaptive controllers highlighting their efforts to make gaming more inclusive.
Not only do you run the risk of offending users with disabilities by forcing a separate experience, this also creates a separate code base to maintain and often developers forget to update text-only versions. I've worked in the accessibility space for years and this concept is an idea of the past and likely to generate a lawsuit. Accessibility lawsuits are popping up left and right in the public sector across every business vertical and I would strongly advise against this.
Chrome has made significant improvements but has several support issues when navigating the web using assistive technologies (ATs). The Lighthouse feature is good for looking at the accessibility tree and testing though. For your testing efforts, I would focus on IE and Firefox for Windows as that is what most users of ATs will be using. Freedom Scientific, the makers of the JAWS screen reader, suggests using the ESR version of Firefox until some bugs that were introduced last fall are resolved (http://blog.freedomscientific.com/mozilla-and-freedom-scient...).
This link might be a bit intimidating but you can review the WCAG (Web Content Accessibility Guidelines) content to see what is required for digital accessibility support.
If you want more concise Best Practices that map to these standards but are a bit less intimidating, check out the Best Practices on webaccessibility.com.
I'm not sure if his needs are more for magnification or of he needs something more so I've documented some information for different types of support.
The built-in screen reader to iOS devices is called VoiceOver and there are many tutorials on YouTube for how to use it. Apple documents a great deal of info on their site for VoiceOver as well as other accessibility options for visual needs. In addition to the screen reader, the iPhone also supports inverted colors, screen magnification, and many other options. If you have an iPhone you can poke around in the Accessibility settings (Settings -> General -> Accessibility).
iPhones are by far the most preferred device for mobile screen readers. WebAIM conducts surveys regarding the most used devices for screen readers which you can review to see adoption.
Glad to see pa11y on the list. It has a nice UI and I would love to do more research about the tool and the automated checks it runs. I know visualizations are lacking from some accessibility tools or are inaccessible if they are used but I like the pa11y dashboards and defect tracking.
There are a ton of things to consider for overall accessibility however one thing developers can do with limited knowledge of accessibility concepts is to use the keyboard to interact with your site(s). Can keyboard-only users complete all the tasks a mouse user can? If there are mouse-driven event handlers on controls, are there redundant keyboard event handlers where applicable? Are labels explicitly associated with form fields? Do images provide proper textual equivalents? Do color schemes provide sufficient color contrast per WCAG (https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-cont...)?
ARIA can provide things like accessible Name/State/Role/Value where it is not provided with custom controls. I think a better place to start would be understanding the requirements of Section 508 and WCAG.
508 is a requirement for the Federal Govt. but WCAG is what most of the private sector is tested against. These standards cover a lot more with respect to accessibility than just what is provided by ARIA. ARIA won't provide things like keyboard functionality but does help ensure that content is conveyed properly.
There are several accessibility concerns with this. There are focus issues with the modals, the images don't provide a proper textual alternative, and more.
Video link: https://www.youtube.com/watch?v=_YISTzpLXCY