Rationale for testing desktop AT rather than mobile AT

[zcorpan]

From #111, @cookiecrook asked why this project starts with testing desktop AT instead of mobile AT. Should we document the rationale for this?

Why desktop screen readers are being tested first. Why not mobile.

• Problems are richer in desktop. Also no clear mobile scope within the ARIA WG. We only test on desktops and don’t know what to do about that.

cc @mcking65

[mcking65]

One question is where to document. We could add a scope rationale slide to the about deck. I am planning to update the background page in the wiki to be in sync with the about deck.

To clarify, the ARIA core-AAM does not include accessibility APIs used in mobile browsers. Thus, there is no mobile browser testing conducted by the ARIA WG. Browser support is an upstream dependency for ARIA-AT. That is, AT can't support ARIA in mobile browsers unless the mobile browsers first support ARIA.

Secondly, the APG examples have not all been engineered and tested for mobile browser support. Some have, but there is a lot of work left to do in order to ensure that the examples are coded in a way that we can expect them to work.

None of this means that the ARIA-AT project couldn't conduct some worthwhile assessment of AT experiences in mobile browsers. But, it does make doing so more complex.