Naur Scope and Format

Hi John and all,

I've looking at your suggestions to divide modalities. Can we discuss 
this when I get back from holidays? Or please go ahead without me and 
update me on the groups thinking.

I'm a little unsure what you are suggesting, as what you are thinking 
when you arranged these below. They seem to be a mix of input and 
outputs.I do agree with what you are saying about potential difficulties 
enumerating e'thing. So I'd like to get others thoughts and discuss this 
further, thanks.

Josh
>
> 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
>
> -- 
>
> Image removed by sender. Marathon Mates Logo 
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarathonmates.rnib.org.uk%2F%3Futm_source%3Drnib%26utm_medium%3Demail%26utm_campaign%3Dmarathon%2520mates%26utm_content%3Demail%2520signature&data=04%7C01%7Cjjwhite%40ets.org%7C90834acd3f044a0711b908d8ead64709%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C637517553325266033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IqGaaxNMaHWh%2BeJgOfp3mE7LS46Yc7KlCB3N7%2B0yh%2FY%3D&reserved=0>
>
>
> 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://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarathonmates.rnib.org.uk%2F&data=04%7C01%7Cjjwhite%40ets.org%7C90834acd3f044a0711b908d8ead64709%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C637517553325275986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CPN3y5e75iuIu1WQvyURPp9%2FGM9klhPAR2MEnBrr%2BW8%3D&reserved=0> 
> 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 
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rnib.org.uk%2F&data=04%7C01%7Cjjwhite%40ets.org%7C90834acd3f044a0711b908d8ead64709%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C637517553325285943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=phZgNLn89cAk0BG1tOB8OXsn%2BKZYhm%2Ffa3B14RzIuyc%3D&reserved=0> 
>
>
>
> ------------------------------------------------------------------------
>
> This e-mail and any files transmitted with it may contain privileged 
> or confidential information. It is solely for use by the individual 
> for whom it is intended, even if addressed incorrectly. If you 
> received this e-mail in error, please notify the sender; do not 
> disclose, copy, distribute, or take any action in reliance on the 
> contents of this information; and delete it from your system. Any 
> other use of this e-mail is prohibited.
>
>
> Thank you for your compliance.
>
> ------------------------------------------------------------------------
> 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)