- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Mon, 21 Jun 2021 12:05:17 +0200
- To: Kim@redstartsystems.com
- Cc: "wai-eo-editors@w3.org" <wai-eo-editors@w3.org>
Hi Kim, Many thanks for your thorough review and thoughtful comments! Please find some responses inline: On 02/06/2021 20:27, Kimberly Patch via WBS Mailer wrote: >> --------------------------------- >> (Updated) Draft Script 1.3.1 "Info and Relationships" >> >> ---- >> (Updated) Draft script for Success Criterion 1.3.1 "Info and >> Relationships" (Nearby: previous version and changes made) >> For each of your comments, please clearly indicate: >> * Location: eg. "SC 1.2.2 - Scene 2" >> * Priority: eg. "[e]" for editorial or "[i]" for important >> * Current wording: >> * Suggested revision: >> * Rationale: >> >> > > * [ ] I am comfortable with this script as it currently is (no changes > suggested) > * [x] Please consider my comments raised in GitHub or in the comments > field below (for editors' discretion) > * [ ] I abstain from commenting and accept the decisions of the Working > Group > Comments: > Priority [e] > Missing word makes it unclear: > ORIGINAL > make it look the headings we saw earlier. > SUGGESTED CHANGE > make it look like the headings we saw earlier. Fixed, thanks. >> --------------------------------- >> (Updated) Draft script for Success Criterion 1.3.3 "Sensory >> Characteristics" >> >> ---- >> (Updated) Draft script for Success Criterion 1.3.3 "Sensory >> Characteristics" (Nearby: previous version and changes made) >> For each of your comments, please clearly indicate: >> * Location: eg. "SC 1.2.2 - Scene 2" >> * Priority: eg. "[e]" for editorial or "[i]" for important >> * Current wording: >> * Suggested revision: >> * Rationale: >> >> > > * [ ] I am comfortable with this script as it currently is (no changes > suggested) > * [x] Please consider my comments raised in GitHub or in the comments > field below (for editors' discretion) > * [ ] I abstain from commenting and accept the decisions of the Working > Group > Comments: > Priority [e] > Editorial suggestion for clarity and consistency: > ORIGINAL > She is browsing around the page and leaning in to read passages of text, > then browse around again… > SUGGESTED CHANGE > She browses around the page and leans in to read passages of text, then > browses around again… Fixed, thanks. >> --------------------------------- >> (Updated) Draft script for Success Criterion 1.3.4 "Orientation" >> >> ---- >> (Updated) Draft script for Success Criterion 1.3.4 "Orientation" (Nearby: >> previous version and changes made) >> For each of your comments, please clearly indicate: >> * Location: eg. "SC 1.2.2 - Scene 2" >> * Priority: eg. "[e]" for editorial or "[i]" for important >> * Current wording: >> * Suggested revision: >> * Rationale: >> >> > > * [ ] I am comfortable with this script as it currently is (no changes > suggested) > * [x] Please consider my comments raised in GitHub or in the comments > field below (for editors' discretion) > * [ ] I abstain from commenting and accept the decisions of the Working > Group > Comments: > Priority [i] > What this has me picturing is a wheelchair user who switches from one app > to another depending on changing orientation needs. But what I suspect is > meant is is a wheelchair user who chooses apps because they will always > work in one particular orientation. > > Editorial comment on clarity: > ORIGINAL > Such apps work for him while he is using the wheelchair and elsewhere. > COMMENT > 'And elsewhere" begs a question (I can't picture what elsewhere is). Is the > issue that the user can't change the orientation or it's difficult for the > user to change the orientation – if so, we should say that clearly. This entire sentence has been removed. >> --------------------------------- >> (Updated) Draft script for Success Criterion 1.3.5 "Identify Input >> Purpose" >> >> ---- >> (Updated) Draft script for Success Criterion 1.3.5 "Identify Input >> Purpose" (Nearby: previous version and changes made) >> For each of your comments, please clearly indicate: >> * Location: eg. "SC 1.2.2 - Scene 2" >> * Priority: eg. "[e]" for editorial or "[i]" for important >> * Current wording: >> * Suggested revision: >> * Rationale: >> >> > > * [ ] I am comfortable with this script as it currently is (no changes > suggested) > * [ ] Please consider my comments raised in GitHub or in the comments > field below (for editors' discretion) > * [ ] I abstain from commenting and accept the decisions of the Working > Group > Comments: > Priority [e] > Editorial for clarity: > ORIGINAL > correcting mistake he made while typing). > SUGGESTED CORRECTION > correcting a mistake he made while typing). > OR > correcting mistakes he made while typing). Fixed, thanks. The sub-group opened issue #69 on this script and welcomes your input: - https://github.com/w3c/wai-wcag-videos/issues/69 >> --------------------------------- >> Draft script for Success Criterion 2.1.1 "Keyboard" >> >> ---- >> Draft script for Success Criterion 2.1.1 "Keyboard" >> For each of your comments, please clearly indicate: >> * Location: eg. "SC 1.2.2 - Scene 2" >> * Priority: eg. "[e]" for editorial or "[i]" for important >> * Current wording: >> * Suggested revision: >> * Rationale: >> >> > > * [ ] I am comfortable with this script as it currently is (no changes > suggested) > * [x] Please consider my comments raised in GitHub or in the comments > field below (for editors' discretion) > * [ ] I abstain from commenting and accept the decisions of the Working > Group > Comments: > Priority [i] > This example seems off in depicting what I see when I look at email apps: > ORIGINAL > Zoom in to part of the application called “attachments” with the > drag-and-drop symbol. The “open file” is not very evident at first. > DETAILS > With Gmail and Proton mail, Thunderbird on a PC, and Apple Mail when you > click on the word or symbol (Paperclip) for attachments, the file browser > comes up, and then you can either copy and click "Open" or "Choose File" > standard for the operating system, or you can drag-and-drop. Or if you > already have the file menu open, you can drag-and-drop. > - The audio instructions imply that there's a button that might not be > easily discoverable in the attachments part of the application, but in all > four of these common email programs you press "attachments" to get the file > system dialog box and the "Open" or "Choose File" buttons that you press > after clicking attachment follow a standard set at the operating system > level so these are standard controls we commonly see across programs. > - It seems off to say "luckily" the email application supports copy and > paste in addition to drag-and-drop when I can't find a standard email > application that doesn't support copy and paste. What am I missing? The sub-group opened issue #64 on this script and welcomes your input: - https://github.com/w3c/wai-wcag-videos/issues/64 >> --------------------------------- >> Draft script for Success Criterion 2.1.2 "No Keyboard Trap" >> >> ---- >> Draft script for Success Criterion 2.1.2 "No Keyboard Trap" >> For each of your comments, please clearly indicate: >> * Location: eg. "SC 1.2.2 - Scene 2" >> * Priority: eg. "[e]" for editorial or "[i]" for important >> * Current wording: >> * Suggested revision: >> * Rationale: >> >> > > * [ ] I am comfortable with this script as it currently is (no changes > suggested) > * [x] Please consider my comments raised in GitHub or in the comments > field below (for editors' discretion) > * [ ] I abstain from commenting and accept the decisions of the Working > Group > Comments: > Priority [e] > Editorial Correction > ORIGINAL > We see him pressing the Backspace-key > CORRECTION > We see him pressing the Backspace key Fixed, thanks. The sub-group opened issue #65 on this script and welcomes your input: - https://github.com/w3c/wai-wcag-videos/issues/65 >> --------------------------------- >> Draft script for Success Criterion 2.1.3 "Keyboard (No Exception)" >> >> ---- >> Draft script for Success Criterion 2.1.3 "Keyboard (No Exception)" >> For each of your comments, please clearly indicate: >> * Location: eg. "SC 1.2.2 - Scene 2" >> * Priority: eg. "[e]" for editorial or "[i]" for important >> * Current wording: >> * Suggested revision: >> * Rationale: >> >> > > * [x] I am comfortable with this script as it currently is (no changes > suggested) > * [ ] Please consider my comments raised in GitHub or in the comments > field below (for editors' discretion) > * [ ] I abstain from commenting and accept the decisions of the Working > Group > Comments: The sub-group opened issue #66 on this script and welcomes your input: - https://github.com/w3c/wai-wcag-videos/issues/66 >> --------------------------------- >> Draft script for Success Criterion 2.1.4 "Character Key Shortcuts" >> >> ---- >> Draft script for Success Criterion 2.1.4 "Character Key Shortcuts" >> For each of your comments, please clearly indicate: >> * Location: eg. "SC 1.2.2 - Scene 2" >> * Priority: eg. "[e]" for editorial or "[i]" for important >> * Current wording: >> * Suggested revision: >> * Rationale: >> >> > > * [ ] I am comfortable with this script as it currently is (no changes > suggested) > * [x] Please consider my comments raised in GitHub or in the comments > field below (for editors' discretion) > * [ ] I abstain from commenting and accept the decisions of the Working > Group > Comments: > Priority [i] > > Scene 1: I would replace the word "flex" with "stretch". This seems like a > small thing, but it's going to make folks with repetitive strain injuries > cringe (already has, in fact). > Scene 2: typo her/he > Scene 3: I haven't seen a content management system with a single key > shortcut for publish, which is good, because that would be bad design (you > don't publish very often and there's a high cost If it's done > accidentally). We should stay away from bad design choices like that in > examples. > Scene 4: This example misunderstands the issue with character key shortcuts > and paints an impossible picture. Single letter shortcuts are a problem for > speech users because anything they say that contains a letter can trip a > single key shortcut, not just if they're spelling a word. So to illustrate > the problem the reporter should say a word that contains the letter in > question rather than spelling it, (or several words with several > shortcuts). > The other thing that's off here is single letter shortcuts can only be > employed when the letter keys are needed for something else – like typing > text. Single letter shortcuts aren't appropriate for anyone in the context > that the video paints. > So single letter shortcuts depend on focus and are conscripted for use only > when users aren't otherwise using letter keys. > For example, Thunderbird has single letter shortcuts that you can use when > the focus is in the inbox (but not when you're composing). > The trouble for speech input users comes when it appears that the focus is > in the body of an email and they dictate several words – a string of > letters – but, surprise, the focus is in the inbox. So instead of putting > words on the screen, however many letters in those words trip shortcuts go > off all at once. This is very easy to do if you're not using a mouse, which > automatically moves the focus to what you are doing. It also happens when > you know you're in your inbox, but someone else comes by and says something > that trips single key shortcuts before you can turn the microphone off. > Scene 5: Another misunderstanding – Shift P is a capital p, and so can > also be tripped by dictation. > I would rework this whole thing with a more realistic scenario. > In general, I think these user videos are more powerful when the steps are > from real user situations. I know we don't necessarily want to mention what > software they're using, and may want to reshoot everything, but I think the > steps in order need to be taken from real scenes that happen with real > users who use the software often for real work. Even if you're > well-informed about a disability and input method, looking in the air to > put together steps without an exact runthrough with real software leaves a > surprisingly large opening for things that don't work to creep in. I've > made a bunch of speech input videos using my everyday set up and when I > plot out a script beforehand I invariably leave something out. It's hard to > picture without actually doing. This script has been put on hold for now due to conflicting suggestions. >> --------------------------------- >> Draft script for Success Criterion 2.3.1 "Three Flashes or Below >> Threshold" >> >> ---- >> Draft script for Success Criterion 2.3.1 "Three Flashes or Below >> Threshold" >> For each of your comments, please clearly indicate: >> * Location: eg. "SC 1.2.2 - Scene 2" >> * Priority: eg. "[e]" for editorial or "[i]" for important >> * Current wording: >> * Suggested revision: >> * Rationale: >> >> > > * [ ] I am comfortable with this script as it currently is (no changes > suggested) > * [ ] Please consider my comments raised in GitHub or in the comments > field below (for editors' discretion) > * [ ] I abstain from commenting and accept the decisions of the Working > Group > Comments: > Priority [e] > > Scene 3: Typo Manit/Manti Fixed, thanks. The sub-group opened issue #67 on this script and welcomes your input: - https://github.com/w3c/wai-wcag-videos/issues/67 Regards, Shadi -- Shadi Abou-Zahra - http://www.w3.org/People/shadi/ Accessibility Strategy and Technology Specialist Web Accessibility Initiative (WAI) World Wide Web Consortium (W3C)
Received on Monday, 21 June 2021 10:07:00 UTC