Re: Apologies for next meeting + Naur Scope and Format

Hi all,

I've added this suggested test by John to this branch

https://github.com/w3c/apa/compare/jpaton-edits-suggestions

Lets discuss if we want to make these changes. Note, I'm off next week 
and like this suggested edit.

Thanks

Josh

> John Paton <mailto:John.Paton@rnib.org.uk>
> Friday 19 March 2021 12:55
>
> Dear all,
>
> I’m on holiday next week so I’ll send my apologies in advance.
>
> In terms of the Naur Scope and format can we change the wording of Req 
> 3 and 4 to
>
> “Support multiple input devices and methods either within the natural 
> language interface/s or via alternatives.” And
>
> “Support multiple output devices and methods either within the natural 
> language interface/s or via alternatives.”
>
> The document needs to be usable for a designer of smart speakers and 
> without the clarification it sounds like the speaker itself needs to 
> support visual/keyboard access rather than the service the speaker 
> provides access to. If you take Echo as the example then enabling 
> users to type natural language queries into the Alexa app satisfies 
> the accessibility requirements and is likely to be more acceptable to 
> users than having to have an external keyboard plugged into the Echo 
> (some of which don’t have screens).
>
> If the document is then divided into modality for inputs and modality 
> for outputs then it may help. Ie.
>
> User need
>
> User has sight loss and so cannot use visual output
>
> Req
>
> NLI (Natural Language Interface) Speech output or
>
> NLI Braille output or
>
> Alternative communication method (outside scope)
>
> User need
>
> User cannot see controls to use them [needs better wording]
>
> Req
>
> NLI Speech input or
>
> Alternative input method (outside scope)
>
> User need
>
> Hearing impairment user prefers to read
>
> Req
>
> NLI Text output or
>
> Alternative communication method (outside scope)
>
> User need
>
> Hearing impairment user prefers captioned speech
>
> Req
>
> NLI Captioned speech output or
>
> Alternative communication method (outside scope)
>
> …
>
> User need
>
> Deaf sign language user cannot speak to device
>
> Req
>
> NLI Sign language input (preferred) or
>
> NLI Text input  or
>
> Alternative communication method (outside scope)
>
> etc
>
> Otherwise almost any combination of X input + y output above is 
> conceivable and you can get in a tangle trying to enumerate them all. 
> By labelling the alternative communication methods as being out of 
> scope we can contain the scope of this document (and maybe usefully 
> signpost to where users should be looking). This means that if a 
> natural language interface is being used for the speech but not the 
> visual interface (such as in a Smart TV) it doesn’t feel like we are 
> trying to force a natural language interface for the visual I/O if one 
> doesn’t make sense. Smart televisions could currently implement a 
> typed command structure similar to Alexa and I suspect that the reason 
> this doesn’t happen is because it doesn’t make sense in the context 
> rather than a lack of a11y awareness (and I can’t see that television 
> accessibility for people with hearing loss has suffered).
>
> It also frees us up to talk about user needs for sign language natural 
> language interfaces despite the fact we are likely a long way from 
> seeing any usable ones. If we have text NLI and “Alternative 
> communication method” as an option then we can alert the reader that a 
> sign language option is preferable while still allowing a text or 
> alternative option until technology catches up. We can then cover 
> alternative word orders and simplified written language structures for 
> signers in the text input section.
>
> We can then handle the user needs for each modality in their own section.
>
>
>     Speech input
>
> User needs include: accents, dialects, speech impediments, etc
>
>
>     Speech output
>
> User needs include: repeat function, etc
>
>
>     Text input
>
> User needs include: textspeak + emojis, spelling, Dyslexia and print 
> disabilities, Signer being forced to use text etc
>
>
>     Text output
>
> User needs include: large fonts, etc
>
>
>     Captioned speech output
>
> User needs include: synchronisation (signpost to media 
> synchronisation?),etc
>
>
>     Braille Output
>
> User needs include: contracted vs uncontracted Braille, support for 
> different sets of contractions (UEB, SEB) etc
>
>
>     Sign language input
>
> User needs include: fingerspelling (if sign not recognised), dialect 
> selection, etc
>
>
>     Sign Language output
>
> User needs include: fingerspelling (if sign not recognised), 
> Large/small signer (for deafblind signers with tunnel vision), dialect 
> selection, etc
>
>
>     Symbol sets and diagrammatical communication
>
> …
>
>
>     Features related to memory
>
> …
>
>
>     Simple interfaces structures and commands
>
> …
>
> This started off simple and got more complicated as I wrote it but I 
> think it handles the issues of 1, clear scope, 2, pan accessibility, 
> 3, advising on user needs without dictating design. It should also 
> still be humanly readable without a separate map.
>
> Best regards,
>
> John
>
> -- 
>
> Marathon Mates Logo 
> <https://marathonmates.rnib.org.uk/?utm_source=rnib&utm_medium=email&utm_campaign=marathon%20mates&utm_content=email%20signature>
>
>
> Whether you’re miles apart or side-by-side, pair up with a mate and 
> run, walk, jog or skip 26.2 miles between you during the month of May. 
> Register for free <https://marathonmates.rnib.org.uk> and set your own 
> fundraising target.
>
> -- 
>
> DISCLAIMER:
>
> The information contained in this email and any attachments is 
> confidential and may be privileged. If you are not the intended 
> recipient you should not use, disclose, distribute or copy any of the 
> content of it or of any attachment; you are requested to notify the 
> sender immediately of your receipt of the email and then to delete it 
> and any attachments from your system.
>
> RNIB endeavours to ensure that all emails and attachments are virus 
> free. We cannot, however, guarantee nor accept any responsibility for 
> the integrity of unsecure email.
>
> We therefore recommend that you use up to date anti-virus software and 
> scan all communications.
>
> Please note that the statements and views expressed in this email and 
> any attachments are those of the author and do not necessarily 
> represent those of RNIB.
>
> RNIB Registered Charity Number: 226227
>
> Website: https://www.rnib.org.uk
>


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