w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire WCAG Video Scripts - Thorough Review 2
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: shadi+eosurvey@w3.org
This questionnaire was open from 2021-05-25 to 2021-06-07.
9 answers have been received.
Jump to results for question:
- Review level
- (Updated) Draft Script 1.3.1 "Info and Relationships"
- (Updated) Draft script for Success Criterion 1.3.3 "Sensory Characteristics"
- (Updated) Draft script for Success Criterion 1.3.4 "Orientation"
- (Updated) Draft script for Success Criterion 1.3.5 "Identify Input Purpose"
- Draft script for Success Criterion 2.1.1 "Keyboard"
- Draft script for Success Criterion 2.1.2 "No Keyboard Trap"
- Draft script for Success Criterion 2.1.3 "Keyboard (No Exception)"
- Draft script for Success Criterion 2.1.4 "Character Key Shortcuts"
- Draft script for Success Criterion 2.3.1 "Three Flashes or Below Threshold"
- Draft script for Success Criterion 2.3.2 "Three Flashes"
1. Review level
summary | by responder | by choice
Summary
| Choice | All responders |
|---|---|
| Results | |
| I reviewed it thoroughly. | 6 |
| I skimmed it. | 3 |
| I didn't get to it. (Abstain and accept the decision of the group.) |
Skip to view by choice.
View by responder
Details
| Responder | Review level | Comments |
|---|---|---|
| Laura Keen |
|
|
| Kris Anne Kinney |
|
|
| Detlev Fischer |
|
|
| Todd Libby |
|
|
| Kimberly Patch |
|
(My strongest areas of expertise are speech input, mixed input, mobile, writing and journalism.) |
| Makoto Ueki |
|
|
| Chris Loiselle |
|
|
| Jade Matos Carew |
|
|
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| I reviewed it thoroughly. |
|
| I skimmed it. |
|
| I didn't get to it. (Abstain and accept the decision of the group.) |
2. (Updated) Draft Script 1.3.1 "Info and Relationships"
summary | by responder | by choice
(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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 4 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 4 |
| I abstain from commenting and accept the decisions of the Working Group | 1 |
Skip to view by choice.
View by responder
Details
| Responder | (Updated) Draft Script 1.3.1 "Info and Relationships" | Comments |
|---|---|---|
| Laura Keen |
|
|
| Kris Anne Kinney |
|
|
| Detlev Fischer |
|
Looks basically good to me. I just note that most content she is likely to have to work with is not provided by authors in users' own company ("Fortunately content authors at her company are trained to markup page structures") - so this could be a confusing signal (implying perhaps, for some in the audience, that deficiencies caused elsewhere can be remedied in the user's organisation). |
| Todd Libby |
|
|
| Kimberly Patch |
|
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. |
| Makoto Ueki |
|
Location: SC 1.3.1 - Scene 6 Priority: [e] Current wording: Fortunately content authors at her company Suggested revision: Fortunately content authors for the website Rationale: It would be rare case that users are using their companies' websites in their daily life. We should make the case more common situation. |
| Chris Loiselle |
|
1) Should blind be capitalized to read as "Blind"? 2) What is meant by page structures? Elements on the page, interactive areas of page? 3) Would the phrasing content areas vs. page structures be a better description of parts of the page? How do we know that the heading underneath the heading is obviously a sub heading? 4) Scene 5 should be written to say that navigating by heading only works, rather than "yet this only works". Unsure of what the visual represents if that is not explained to the audio based user / consumer of the video. Are they being provided with information that the text / code changes from unstructured to structured? |
| Jade Matos Carew |
|
|
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
3. (Updated) Draft script for Success Criterion 1.3.3 "Sensory Characteristics"
summary | by responder | by choice
(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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 5 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 3 |
| I abstain from commenting and accept the decisions of the Working Group | 1 |
Skip to view by choice.
View by responder
Details
| Responder | (Updated) Draft script for Success Criterion 1.3.3 "Sensory Characteristics" | Comments |
|---|---|---|
| Laura Keen |
|
|
| Kris Anne Kinney |
|
|
| Detlev Fischer |
|
Looks good to me. |
| Todd Libby |
|
|
| Kimberly Patch |
|
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… |
| Makoto Ueki |
|
Location: SC 1.3.3 - Scene 4 Priority: [i] Current wording: “press the button at the end of this form” Suggested revision: “press the OK button at the end of this form” Rationale: It is still rely on the location only. There might be multiple button there. It is very imporatnt to identify the label of the button and the button has its label on it. |
| Chris Loiselle |
|
Scene 1: Audio: She has a large screen and uses software to magnify content, large screen – computer screen , tv monitor, what size? Scene 1: Visual : Browsing then browse around again phrasing does not read well. Scene 2: Audio: Should talk to reflow as “appearing in different positions”. Scene 2: Visual: things should be changed to specific content , or components, i.e. the buttons mentioned in the audio script. Hard to understand e.g. sidebar without actual visual example. If this is the visual, the audio should talk to that example then. |
| Jade Matos Carew |
|
|
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
4. (Updated) Draft script for Success Criterion 1.3.4 "Orientation"
summary | by responder | by choice
(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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 6 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 2 |
| I abstain from commenting and accept the decisions of the Working Group | 1 |
Skip to view by choice.
View by responder
Details
| Responder | (Updated) Draft script for Success Criterion 1.3.4 "Orientation" | Comments |
|---|---|---|
| Laura Keen |
|
|
| Kris Anne Kinney |
|
|
| Detlev Fischer |
|
Looks good to me (an alternative would be a 'door slam' message like "Please turn your device to portrait orientation" or similar) |
| Todd Libby |
|
|
| Kimberly Patch |
|
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. |
| Makoto Ueki |
|
|
| Chris Loiselle |
|
Scene 3 - talks to the issue visually, however isn't expressed in the audio version of the script, i.e. that tablet mounted in landscape with portrait view is presenting text sideways to Jan. Scene 4 - what is the definition of working well ? The app is displayed in landscape mode and is fully functionable? |
| Jade Matos Carew |
|
|
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
5. (Updated) Draft script for Success Criterion 1.3.5 "Identify Input Purpose"
summary | by responder | by choice
(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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 3 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 4 |
| I abstain from commenting and accept the decisions of the Working Group | 1 |
(1 response didn't contain an answer to this question)
Skip to view by choice.
View by responder
Details
| Responder | (Updated) Draft script for Success Criterion 1.3.5 "Identify Input Purpose" | Comments |
|---|---|---|
| Laura Keen |
|
|
| Kris Anne Kinney |
|
The last line of the script "Jonathan can also use the saved entries for other websites that use correct coding of input fields." makes it sound like he can use that same username and password on other websites since that is what this video is talking about. Should the video example be something like address fields when ordering so that it's more universal across different websites? |
| Detlev Fischer |
|
This conveys the idea that the critical point of 1.3.5 is automatically inserting content stored in the browser via the autocomplete attribute. It is not, so this video is misleading. Autocomplete was used because no other fitting attribute for purpose was available at the time of writing the SC. The idea of 1.3.5 is to provide a language-independent identification of user purpose so that novel assisitive technology could provide help in some other mode, such as displaying extended descriptions of purpose or visual icons for elements such as "name" (a user image?) telephone, email, address, etc. To my knowledge (correct me if I am wrong), no usable implementation of such an assistive technology has been produced since 2.1 was released 3 years ago. I would skip this SC in the videos since there are no known benefits as yet. I would actually propose to seriously consider shelving the SC in the next version of WCAG if there is no sign that it is going to provide any benefit in real world contexts. |
| Todd Libby |
|
The line "We see Jonathan using the auto-complete for username (and maybe also password) on a different log-in page (for another website)." concerns me because it could convey that Jonathan can use the same username and password on any other sites he navigates to. |
| Kimberly Patch | 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). | |
| Makoto Ueki |
|
|
| Chris Loiselle |
|
Scene 2 - We see a form asking for “Username” and “Password”, and he seems to have trouble typing in the username (he keeps reviewing the numbers and correcting mistake he made while typing). Mistake should be mistakes ? Or perhaps the letter "a" prior to word mistake. Scene 3 - The visual and audio script wording is confusing. If this is Jonathan's computer, why would he have different usernames to choose from? Would it be better to allow him to choose from one username that auto populates in the example to simplify the example. I.e. if his username is based on an identification number, he'd be choosing a specific username and probably using a specific one rather than choosing from a list of usernames. |
| Jade Matos Carew |
|
|
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
6. Draft script for Success Criterion 2.1.1 "Keyboard"
summary | by responder | by choice
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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 1 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 7 |
| I abstain from commenting and accept the decisions of the Working Group | 1 |
Skip to view by choice.
View by responder
Details
| Responder | Draft script for Success Criterion 2.1.1 "Keyboard" | Comments |
|---|---|---|
| Laura Keen |
|
[i] Scene 1 Visual should be: We 'see' the screen and the email application opening and the message being started as she speaks the commands. |
| Kris Anne Kinney |
|
Why do we need "also" in the first sentence? |
| Detlev Fischer |
|
2.1.1 Keyboard Seems to focus on the keyboard interface (speech use) not keyboard input per se. This is valild but it may be easier if one (the default) video would focus on actual keyboard use? There also seems to be a missing part where the file is actually selected by the keyboard alternative to the drag-n-drop function. This may be clear visually, but it is not obvious from the audio. |
| Todd Libby |
|
In the first scene, "She has a headset and using speech to operate the computer." seems to make more sense if it were "She has a headset and **is** using speech to operate the computer." Also, "We the screen and the email application opening and the message being started as she speaks the commands." reads better if it is something like, "We **see** the screen and the email application open, the message starts as she speaks the commands." |
| Kimberly Patch |
|
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? |
| Makoto Ueki |
|
Location: SC 2.1.1 - story Priority: [i] Current wording: “ She uses voice commands to operate the computer and speech recognition software to type text.” Suggested revision: It is one of use cases. But it might be better that the video focuses on those who rely on keyboards when interacting with web content. Rationale: It is difficult for people to understand how voice commands and speech recognition software have something to do with keyboard operability. Understanding WCAG document is saying, in the "Intent" section, "When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators." https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html#intent |
| Chris Loiselle |
|
Scene 1 - Visual talks to sip and puff , however audio script doesn't mention it. Do you want these to align to tell same story or have one thing said visually with audio not mentioning that particular attribute of Niando's experience? Scene 2 - Instead of "for this to work properly" , recommendation would be to change phrasing to "for Niando to open and write an email" Reading through this script, the audio script sometimes tells the story and sometimes the visual tells the story, with one relying on the other to tell the whole story. Scene 2 talks to need for keyboard interface support but goes right into an example of mouse drag and drop within the same paragraph. The visual talks to open file, but that is not expressed in the audio version of script. The visual tells the constraint, yet the audio doesn't. Scene 3 - Script for scene 3 doesn't seem finished. Scene 4 - Previous scenes talk to adding an attachment. This scene talks to visual script showcasing that file was selected, but audio based script doesn't go into detail of how she did it. We just had her saying "send message". |
| Jade Matos Carew |
|
|
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
7. Draft script for Success Criterion 2.1.2 "No Keyboard Trap"
summary | by responder | by choice
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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 5 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 2 |
| I abstain from commenting and accept the decisions of the Working Group | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Draft script for Success Criterion 2.1.2 "No Keyboard Trap" | Comments |
|---|---|---|
| Laura Keen |
|
|
| Kris Anne Kinney |
|
|
| Detlev Fischer |
|
An example where no key can move the focus may be better. (e.g. a script re-focussing a field when the next field is tabbed to). What is odd in the example is adding ENTER as a key to just dismiss the datepicker. ENTER would most likely already be used to insert the currently selected date into the date field. So this should be made clearer if the datepicker example is retained. |
| Todd Libby |
|
|
| Kimberly Patch |
|
Priority [e] Editorial Correction ORIGINAL We see him pressing the Backspace-key CORRECTION We see him pressing the Backspace key |
| Makoto Ueki |
|
|
| Chris Loiselle |
|
|
| Jade Matos Carew |
|
Suggest different text for scene 5, somehing like 'Brami can now use his mouth stick comfortably and effectively when using this app.' |
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
8. Draft script for Success Criterion 2.1.3 "Keyboard (No Exception)"
summary | by responder | by choice
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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 2 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 5 |
| I abstain from commenting and accept the decisions of the Working Group | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Draft script for Success Criterion 2.1.3 "Keyboard (No Exception)" | Comments |
|---|---|---|
| Laura Keen |
|
[i] Scene 1 Visual should be: We 'see' the screen with a drawing application and the “draw line” function being started as she speaks the commands. |
| Kris Anne Kinney |
|
Same user as in 2.1.1, same comment, why do we need also - does being a middle school student matter? It's not said in the 2.1.1 video. |
| Detlev Fischer |
|
The example focuses an an act of drawing a straight line which does only depend on start and end point? So the video seems to be missing the point. A more convincing example might be inserting an electronic signature via keyboard rather than signing with a stylus or mouse? |
| Todd Libby |
|
Not sure of the necessity for "Niando is a middle school student." and the word "also" in, "he has muscular dystrophy, which also impacts her arms." There is also a typo. "[We hear **Naindo** (Niando) say the commands “draw line”]" |
| Kimberly Patch |
|
|
| Makoto Ueki |
|
Do we need the video for SC 2.1.3 in the first place? I think it would be good enough if we have the video for SC 2.1.1. People can understand how important the keyboard operability is. If we have both, it will be needed to describe the difference between 2.1.1 and 2.1.3. |
| Chris Loiselle |
|
|
| Jade Matos Carew |
|
|
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
9. Draft script for Success Criterion 2.1.4 "Character Key Shortcuts"
summary | by responder | by choice
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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 1 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 6 |
| I abstain from commenting and accept the decisions of the Working Group | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Draft script for Success Criterion 2.1.4 "Character Key Shortcuts" | Comments |
|---|---|---|
| Laura Keen |
|
[i] Scene 4 audio should be: For example, if 'he' is spelling a word with the letter “P” or saying something that sounds similar to it. [We hear Alex saying “P-O-box”] [i] Scene 5 visual should be: We see configuration 'settings' not seetings... |
| Kris Anne Kinney |
|
I think the first sentence is too long and should be broken up into two sentences. Alex has been a reporter for many years and has developed a repetitive strain injury. This makes it painful to use a mouse and to type for extended periods of time. Is Alex a he or a she? 2nd section says her, but I think its a typo and you meant to say he. |
| Detlev Fischer |
|
The example should use modifier keys like ALT or Ctrl rather than the shift key. I believe the shift key is not meant to be considered a modifier key for keyboard shortcuts (compare https://www.w3.org/WAI/WCAG21/Techniques/general/G217). |
| Todd Libby |
|
Typo: "[We hear Alex speak into his **heaset** (headset) dictating a news article]", "For longer passages of text, such as his article, **her** (he) prefers to use dictation software that converts his speech to text.", I think use of the Shift key in #5 should be replaced with either the Alt key or the Control key, since those are more widely used for keyboard interactions with content management systems in my experience. |
| Kimberly Patch |
|
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. |
| Makoto Ueki |
|
+1 to Detlev |
| Chris Loiselle |
|
|
| Jade Matos Carew |
|
|
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
10. Draft script for Success Criterion 2.3.1 "Three Flashes or Below Threshold"
summary | by responder | by choice
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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 3 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 2 |
| I abstain from commenting and accept the decisions of the Working Group | 3 |
(1 response didn't contain an answer to this question)
Skip to view by choice.
View by responder
Details
| Responder | Draft script for Success Criterion 2.3.1 "Three Flashes or Below Threshold" | Comments |
|---|---|---|
| Laura Keen |
|
[i] scene 3 visual should be: We see 'Manti' not Manit ... |
| Kris Anne Kinney |
|
|
| Detlev Fischer |
|
Looks alright to me. |
| Todd Libby |
|
"Manti has photosensitive reactions to certain types of flashing lights, such as strobe lights on the computer screen.". "Strobe lights" doesn't read right to me and would suggest "flickering images such as animated GIFs" or something similar. "such as images of strobe lights" is something tht I would lso suggest as well. All these things I have experienced when some content like this has triggered my migraine headaches. |
| Kimberly Patch | Priority [e] Scene 3: Typo Manit/Manti | |
| Makoto Ueki |
|
Except for typo in Scene 3. |
| Chris Loiselle |
|
|
| Jade Matos Carew |
|
Abstaining here, isn't this one being held back for now? |
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
11. Draft script for Success Criterion 2.3.2 "Three Flashes"
summary | by responder | by choice
Draft script for Success Criterion 2.3.2 "Three Flashes"
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:
Summary
| Choice | All responders |
|---|---|
| Results | |
| I am comfortable with this script as it currently is (no changes suggested) | 2 |
| Please consider my comments raised in GitHub or in the comments field below (for editors' discretion) | 4 |
| I abstain from commenting and accept the decisions of the Working Group | 3 |
Skip to view by choice.
View by responder
Details
| Responder | Draft script for Success Criterion 2.3.2 "Three Flashes" | Comments |
|---|---|---|
| Laura Keen |
|
|
| Kris Anne Kinney |
|
Just a question - are there streaming services like this? Wondering if it really helps understand the SC of not building flashing content into media. It's on the content authors not to put flashing content in the content, not the streaming service? this one was the hardest for me to directly relate to the SC since it's not directed to the people authoring the content. |
| Detlev Fischer |
|
The video does not seem to really illustrate the point - in contrast to 2.3.1 it should have a small permanently flashing control, that possibly appears large due to strong zoom in? So this would pass 2.3.1 (small area) but fail 2.3.2. |
| Todd Libby |
|
"Manti has photosensitive reactions to certain types of flashing lights, such as strobe lights on the computer screen." Again, I'd suggest using some wording other than "strobe lights" when conveying this message, to something such as my suggestion in 2.3.1 |
| Kimberly Patch |
|
|
| Makoto Ueki |
|
Location: SC 2.3.2 - Scene 3 Priority: [i] Current wording: "Fortunately her preferred streaming app does not use videos with flashes that cause her to have migraines" Suggested revision: Rationale: Understanding Success Criterion 2.3.2: Three Flashes https://www.w3.org/WAI/WCAG22/Understanding/three-flashes.html#intent It reads "The intent is to guard against flashing larger than a single pixel, but since an unknown amount of magnification or high contrast setting may be applied, the prohibition is against any flashing." Why don't we merge SC 2.3.1 and 2.3.2 in one video? While Level A has exceptions, we should encourage them to avoid "anything that flashes more than three times in any one second period". |
| Chris Loiselle |
|
|
| Jade Matos Carew |
|
I wasn't sure if this one was ready either. I think it could do with more input from the SC, especially as it talks about limits and the video suggests not using flashing at all. |
| Tzviya Siegman |
|
View by choice
| Choice | Responders |
|---|---|
| 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 |
|
More details on responses
- Laura Keen: last responded on 28, May 2021 at 14:09 (UTC)
- Kris Anne Kinney: last responded on 28, May 2021 at 15:41 (UTC)
- Detlev Fischer: last responded on 31, May 2021 at 14:19 (UTC)
- Todd Libby: last responded on 2, June 2021 at 15:23 (UTC)
- Kimberly Patch: last responded on 2, June 2021 at 18:25 (UTC)
- Makoto Ueki: last responded on 3, June 2021 at 03:03 (UTC)
- Chris Loiselle: last responded on 3, June 2021 at 13:02 (UTC)
- Jade Matos Carew: last responded on 4, June 2021 at 08:39 (UTC)
- Tzviya Siegman: last responded on 4, June 2021 at 13:29 (UTC)
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project