[RAUR] General feedback/suggestions

[matatk]

I wanted to give the RAUR a read-through before voting. Naturally I think it is pretty ace :-). The user needs come across as comprehensive, well thought out and clearly explained. The following suggestions are small refinements for future versions.

§Introduction - there's a link to the IETF standard, but not WebRTC (not sure there needs to be, but it seemed un-symetrial).

§1 - "Working Group" is written instead of the acronym "WG", in most cases, but not all, and other acronyms like "IG" and "AG" are not expanded.

• "Web and Networks IG" could be "Web and Networks Interest Group"
• "Second Screen" should indicate what sort of group it is (it may be a Working Group, as a Working Group follows but it's not made plural).
• If the ordering of the WGs/IGs doesn't matter, then you could put all the WGs first and just put "Working Groups" after them, and then follow with the IGs etc.
• I think "AG" should be expanded to "Accessibility Guidelines".
• Likewise with "APA". The first use of "Accessible Platform Architectures" is in the Status section, so maybe "(APA)" could be appended there?
• If the acronyms are to be used again, you could put things like "(IG)" after the first, expanded, use.

§2 - Wondering if we can define the term without re-using the word "needs"... would the following work: "User needs relate to the support a particular user requires from an application..."?

§2 - "RQTF" was not previously expanded.

§3.1 Note 1 - This is a nice example. Is it saying that, because the four items are on the same Braille display, and because of how these displays work, all of the items have to be updated at the same time, even though they're not related? If so, could we add something to clarify this, such as "then due to the nature of the technology involved, they would all be updated at the same time."? (Also, is this definitely how such displays still all work, if so?)

§3.3 - Could we have some suggestions as to preferences involved? E.g. font size may come from the OS, or the UA, or maybe the app if it is specifically coded that way. I imagine other preferences may include things like whether closed captions are desired.

§3.5 - I'm wondering if we should have some sort of demarcation between user needs lists, e.g. a lower-level heading, or at least giving the lists an accessible name? A heavier approach would be to have user needs at the outer level and requirements be nested (though this would be a big change and would probably need to apply to the XAUR too, for consistency).

§3.6 Note - should be "from the user's operating system."

§3.10 Note - is it worth making the option of having everything encrypted a user need too? Or would it already be covered by existing standards?

§3.11 - should be "of the user's choosing."

§3.13 - I think "AAC" needs expanding (first use).

§3.15 - very nice :-).

§3.16 - "TTS" is expanded in the Note, as opposed to on first use.

§6 - This table is really helpful, but I find it quite hard to read without horizontal lines. I would recommend against using vertical lines if possible, but definitely horizontal lines would be of great help.

§6 (and in other places) - wondering if it would help, at least in the table, to make the WG/IG/other names links to those groups? It may make things a bit too busy but it seems like it'd be helpful to the reader who's starting to get interested in learning more, from reading this document.

§6 - should the "NOTE:"s in the table be styled as they are elsewhere, or at least separated by a paragraph break?

§A - The change log is very helpful to have, but it doesn't give a point of reference: since when were these changes made?

[RealJoshue108]

Thanks @matatk - much of this will be useful for final tidy up :-)
We have some further comments to process, and are working on that - but I can use this as a handy checklist for final pass. Ta.

[RealJoshue108]

@matatk When you ask:

§3.1 Note 1 - This is a nice example. Is it saying that, because the four items are on the same Braille display, and because of how these displays work, all of the items have to be updated at the same time, even though they're not related?

No, it's stating that sections of the braille display may need to be pinned if they are related. They may also be independant, but this is dependent on the 'state' of an atomic section, and how it may relate to another section. I hope this is clear. In short the user need is such that atomic elements may need to ascribed to parts of a Braille display - as they can be divided into sections.

I hope this is clearer - in this context does your reading of the note make sense or do you think that it needs to be clarified further? Tnx.

[RealJoshue108]

@matatk

§3.3 - Could we have some suggestions as to preferences involved? E.g. font size may come from the OS, or the UA, or maybe the app if it is specifically coded that way. I imagine other preferences may include things like whether closed captions are desired.

I think this is better slightly loosely specified. There may be RTC specific preferences that should be maintained so keeping the definition here loose would help cover those instances.

[RealJoshue108]

@matatk I'm not sure I understand the following, do mean in terms of how this document is presented?

§3.5 - I'm wondering if we should have some sort of demarcation between user needs lists, e.g. a lower-level heading, or at least giving the lists an accessible name? A heavier approach would be to have user needs at the outer level and requirements be nested (though this would be a big change and would probably need to apply to the XAUR too, for consistency).

[RealJoshue108]

Very helpful (and completist) editorial pass @matatk - appreciated :-)

[matatk]

Here are some replies on the questions you asked; hope this helps...

§3.1 Note 1 - This is a nice example. Is it saying that, because the four items are on the same Braille display, and because of how these displays work, all of the items have to be updated at the same time, even though they're not related?

No, it's stating that sections of the braille display may need to be pinned if they are related. They may also be independant, but this is dependent on the 'state' of an atomic section, and how it may relate to another section. I hope this is clear. In short the user need is such that atomic elements may need to ascribed to parts of a Braille display - as they can be divided into sections.

I hope this is clearer - in this context does your reading of the note make sense or do you think that it needs to be clarified further? Tnx.

Ah, thanks for this, that does make sense. I think the thing that'd thrown me slightly was the "if" part (it made me anticipate additional content). I wonder if this, slightly shorter version would work:

"For example, an 80 character braille display could be sectioned to display 4 atomic items in up to 19 spaces each (leaving at least one blank cell for spacing)."

---

ACK regarding keeping the notion of "user preferences" in §3.3 loose.

---

@matatk I'm not sure I understand the following, do mean in terms of how this document is presented?

§3.5 - I'm wondering if we should have some sort of demarcation between user needs lists, e.g. a lower-level heading, or at least giving the lists an accessible name? A heavier approach would be to have user needs at the outer level and requirements be nested (though this would be a big change and would probably need to apply to the XAUR too, for consistency).

Yes, just in terms of how it's presented. In some sections (such as §3.5) there are three separate user needs. They're expressed using three separate lists, with slightly increased spacing between the lists (relative to between list items in one list).

So I think what I'm saying is, right now we have something like this (in markdown terms):

* User need 42
* Requirement 42a: Arthur
* Requirement 42b: Dent

* User need 43
* Requirement 43a: Ford
* Requirement 43b: Prefect

and I was wondering if either of the following (or something else) may be clearer...

* User need 42
  + Requirement 42a: Arthur
  + Requirement 42b: Dent

* User need 43
  + Requirement 43a: Ford
  + Requirement 43b: Prefect

or maybe

### User need 42

* Requirement 42a: Arthur
* Requirement 42b: Dent

### User need 43

* Requirement 43a: Ford
* Requirement 43b: Prefect

I'm wary of suggesting it be re-structured significantly but maybe something to just help ease readability by making it clearer the three separate lists in §3.5 are indeed separate. If you are able to change the stylesheet to put more space between the lists, that's another approach that wouldn't affect the structure at all.