Re: 48-Hour Call for Consensus (CfC): Publish XAUR FPWD

Great input Mike *grin

Really helpful.. at this point any of the substantive non-editorial/type 
fixes (which I'll happily deal) with could go into GH as Issues please, 
with the XAUR label. I don't want to make more work for you but doing 
that will help track e'thing, initiate discussion and so on.

So please go for it as GitHub issues on https://github.com/w3c/apa

Or if it is helpful I can add these as issues - assign them to me 
(happily attribute them to you etc) and take it from there. Let me know.

Much appreciated Matthew :-)

Josh

Matthew Tylee Atkinson wrote on 28/01/2020 23:45:
> I support this going to FPWD.
>
> It was an enjoyable read and will be a helpful resource.
>
> Here are some questions, observations and typos from my review. (I realise there's quite a bit here - sorry I only got to this now - and I don't think that any of it should block publication as a FPWD.)
>
> I have not yet reviewed the related documents in section 5, but intend to do so.
>
> best regards,
>
>
> Matthew
>
>
> // Things that may need clarifying
>
> * [3] The domain/site says it's "WalkinVRDriver" (we have "Walking"). Also, it sounds like this should be a link, to provide context? (In §3.5 it's presented as a link.)
>
> * [3] I realise it may just be a character limit in the footnote IDs, but is it possible to call the "able-game" footnote ID "able-gamers" as that's their full name?
>
> * [3.2] "There will be many modality aspects for the developer and/or content author to consider:" - it looks like there's going to be a list of things there, but a "NOTE:". (The section ends by saying what's coming up in the input section, so I'm not sure if the colon relates to "the following sections".)
>
> * [3.5] The Xbox Adaptive Controller is mentioned. At the moment I'm not sure that it /is/ supported as an XR controller (ref our discussion about the WebVR Gamepad Module [0]) - though it certainly sounds like that would be a good idea for accessibility.
>
> * [3.6] I'm not clear on the first sentence. I mean it seems to stand alone. (The point of the section as a whole that this is an important requirement is an important one, of course.)
>
> * [3.7, 3.8] I think a great example that seems close to this, but not quite the same thing, is Xbox's co-pilot feature, which lets two people use two separate controllers, but to control one player character. This allows someone with disabilities to have a buddy who helps them with the bits that they find less/in-accessible. I wonder if it's worth mentioning somewhere around here as an example of good practice in the industry? [1]
>
> * [3.9] Some great points here. I wonder if this is an appropriate place for some examples.
>
>      - Do I understand correctly that the first point is about things that in the real world may be inherently accessible affordances, like tactile paving, or the presence of a handle or a plate on a door, but we are trying to figure out how to expose those in a natural way to the XR user?
>
>      - The last point is important and evokes two different situations for me - are these the ones you are describing and/or, if not, do you think either warrants mentioning?
>
>          a. Situations in which an underlying interaction is presented in a certain way, because it works for most people. But then, assistive technology is layered on top of that interaction in its rendered modality, but it would've been simpler for the user to have had a different representation. A classic example of this is drag-and-drop, which is frequently represented visually on web pages. It is possible to use ARIA etc. to convey things like draggable things and drop zones (making the problem 2D in some cases), but in many cases it may've been simpler to present the problem as specifying the order of items in a list, which can be done as a simple 1D problem with numbers or up/down keystrokes/buttons as inputs. This is a problem of adapting a particular rendering of the problem rather than the underlying problem.
>
>          b. Situations in which an adaptation has been carried out to transform one modality into another, to make it accessible, but we need a way to convey the user's interaction in the adapted modality back into the original one. E.g. reading a book in XR may be presented visually, with page-turning gestures required, but if a screen-reader is being used to read the text, keyboard interactions may be more suitable for the user. This is a problem of bridging between AT and content, and may imply the need for an accessibility layer for XR.
>
> * [4.x, 4.6] The section on voice commands really made me think, as with other user needs sections, that we need existing AT to be able to work with XR, where it makes sense, in order to avoid wheel reinvention. Having said that, content design choices can make so much difference and ensure that people are kept immersed in the world, rather than being brought back out by the experience of using traditional AT. I think the focus on user needs - not how to meet them - is very helpful here, as those needs are not going to change.
>
> * [4.7] Can we add an extra requirement that says that the content is designed so that shape is used instead of just colour? I suggest that because if the requirement is met, and the user has only minor difficulties with contrast, that could be sufficient for them to not need to engage any specific display mode, and thus be a more immersive experience. There are several examples from the world of games that we could reference [2] (that list actually misses one that I think is particularly good, but I’d have to ask Ian about it, as I can’t remember the name of the game I’m thinking of at the moment).
>
> * [4.8] Can we add an extra requirement to allow for scalable font sizes in both UI and content? This could negate the need for screen magnification. This (and many other adaptations, even at the same time) has been done successfully in research [3], and APIs like Dynamic Text on iOS and large text on Android are getting close.
>
> * [4.16] I'm not an expert on this, but I am wondering if mono audio should be provided as an alternative for people with hearing impairments (as opposed to, or in addition to, the proposed)?
>
>
> // Housekeeping questions
>
> * Shouldn't the URL for the Latest Published Version use upper-case "XAUR" and not lower-case "xaur" to match the acronym case of the "TR" in the URL? Also, WCAG's URL includes upper-case "WCAG" and not lower-case "wcag".
>
> * The names of the APA XR accessibility docs are called just "XR" and don't refer to "WebXR" - is that to help disambiguate it from the WebXR WG's docs, or because APA is talking about general XR (web or native)?
>
> * [4.x] It would be really neat, for when people are talking about the XAUR, if the section numbers could be made to match the user need numbers.
>
>
> // Typos
>
> * [1.1, 4.1] 360° is typed using a superscript 0 - should be ℃
>
> * [1.2, 1.3] "computer-mediated" (with the hyphen) may be slightly clearer?
>
> * [3.3] Would it be clearer if the note started its own paragraph (this may well be overridden by W3C house style, with which I'm unfamiliar :-)).
>
> * [3.3] In the first three input device description, the apostrophe that should be in "user's" is missing.
>
> * [3.3] The eye-tracking description refers to voice.
>
> * [3.5] I gather the official spelling is "Xbox" (not "XBOX").
>
> * [4.2] REQ 1 should be REQ 1b.
>
>
> // Bits I particularly liked
>
> It was all very helpful and a comprehensive introduction to XR, but...
>
> * [3] "Gamification of VR forces game dynamics on the user..." - I had a question/suggestion here but it was answered in the sixth of the last set of bullet points at the bottom of the section :-). Also the point about authoring tools is a vital one.
>
> * [3.2] I thought the way accessibility was cast in the context of multimodality is really neat.
>
> * [4.12, 4.19] Particularly great requirements :-).
>
>
> I’d be happy to file all of these as GitHub issues on <https://github.com/w3c/apa> if that helps (or if you would prefer I only file a subset, please let me know).
>
> best regards,
>
>
> Matthew
>
> [0] <https://lists.w3.org/Archives/Public/public-apa/2020Jan/0019.html>
> [1] <https://beta.support.xbox.com/help/account-profile/accessibility/copilot>
> [2] <http://gameaccessibilityguidelines.com/ensure-no-essential-information-is-conveyed-by-a-colour-alone/>
> [3] <http://www.eecs.harvard.edu/~kgajos/research/supple/>
> [4] <http://gameaccessibilityguidelines.com/avoid-repeated-inputs-button-mashingquick-time-events/>
>


-- 
Emerging Web Technology Specialist/Accessibility (WAI/W3C)

Received on Wednesday, 29 January 2020 09:57:16 UTC