Apologies for next meeting + Naur Scope and Format

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


--

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 at https://marathonmates.rnib.org.uk and set your own fundraising target.

--


DISCLAIMER:

NOTICE: 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 emails and any attachments generated by its staff are free from viruses or other contaminants.  However, it cannot accept any responsibility for any  such which are transmitted.

We therefore recommend you scan all attachments.

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