This is a survey for the WAI Curricula Task Force to discuss changes based on EOWG's Monkey Review survey.

Preview with proposed changes is at: https://deploy-preview-273--wai-curricula.netlify.com/curricula/developing-accessible-content/

Please go through the following questions and provide any specific feedback you have, especially if you don't agree with the proposed changes.

Remember: These are the proposed changes based on EOWG's Monkey Review.

Next step is to bring the whole curriculum back to EOWG for Butterfly Approval (Approval to publish) survey, once we refine the proposed changes within the Task Force.

Details

The following is a list of general changes based on EOWG's Monkey Review.

• Change explanatory sentence at the "topics to teach level":
  from "Optional topics to achieve the learning outcomes"
  to "Topics to achieve the learning outcomes".
  Rationale: A specific order or teaching method is not required, but all topics are recommended for the teaching sequence.
• Changed idea to assess knowledge for module: "Practical — Students are guided to use mechanisms that assistive technologies provide to [...]"
  from "Short answer questions"
  to "Practical",
  Rationale: It better reflects the assessment type.

• Do you agree with these additions?
• Do you have any further comments?
• Any suggestions on how to better communicate these changes?

  Details

  Responder	Comments
  Daniel Montalvo
  Gerhard Nussbaum	I'm ok with the changes.
  Dónal Fitzpatrick	I think these additions add clarity to the material and thus I agree.
  David Sloan	I agree with removing "optional" from "optional topics". But I'm uncomfortable with the phrase "Topics to achieve the learning outcomes". I propose a rewording "Topics to support students in achieving the learning outcomes" Rationale: It's students who achieve learning outcomes, not topics. I agree with the change from "Short answer questions" to "Practical"

The following is a list of added or reworded learning outcomes based on EOWG's Monkey Review.

• [Module 1] [Topic Section Headings] -- "explain how headings provide a summary of page content that can be navigated by assistive technologies such as screen readers"
• [Module 2] -- "identify and code appropriate keyboard controls for interactive menus"
• [Module 4] -- "summarize related requirements for authors and designers to provide information about the relationships between header and data cells"
• [Module 4] [Topic Simple Tables] -- "define simple tables as those which contain one row or column header"
• [Module 4] [Topic Simple Tables] -- "summarize related requirements for designers and content authors to use CSS techniques for avoiding table layout designs"
• [Module 4] [Topic: Complex Tables] -- "define complex tables as those which contain multiple row and column headers"
• [Module 5] [Topic Form Labels] -- Qualify use of the different techniques to label form controls. Added "explain how labels are used by users of voice control software to activate and interact with form controls"
• [Module 5] [Topic Form Instructions] -- "summarize related requirements for designers to provide mechanisms that consolidate already entered data”
• [Module 5] [Topic Validation and Notifications] -- “explain how each of these methods of notifications benefit people with disabilities"
• [Module 6] [Topic Keyboard and Focus Management] -- "summarize related requirements for designers to provide different choices for users when selecting options in complex widgets, such as typing to narrow results"
  • Do you agree with these additions?
  • Do you have any further comments?
  • Any suggestions on how to better communicate these changes?

    Details

    Responder	Comments
    Daniel Montalvo
    Gerhard Nussbaum	I'm ok with these changes.
    Dónal Fitzpatrick	I agree with the additions.
    David Sloan	I agree with the edits with the following exceptions: Module 2: I'm unclear what "identify and code appropriate keyboard controls for interactive menus" refers to. "Controls" could mean individual interactive items in a menu. I think what we are referring to is "code appropriate keyboard operation for interactive menus"? This would align more closely with the third LO for the Fly-out menu topics. Module 4 Topic Simple Tables: I'm confused by the definition of a simple table as one with only one row or column header. That sounds like a list rather than a table. I wonder if what we mean is that a simple table has "one row or column of headers"? Module 4 Topic Complex Tables: Related to the previous comment, i suggest complex tables are those that contain "multiple rows and/or columns of headers". Module 5 Topic Form Instructions: I'm confused by the word "consolidate", so this learning outcome is unclear to me. I'm not sure what change to address until I better understand what kind of requirements are being referred to. Module 6 Topic Keyboard and Focus Management: I suggest a slight rewording: "summarize related requirements for designers to provide different choices for users when selecting options in complex widgets, such as refining a set of search results"

The following is a list of added ideas to assess knowledge based on EOWG's Monkey Review.

• [Module 3] [Topic Complex Images] -- Reduced scope of assessment
  Original: "Practical — Students are shown charts and graphics without descriptions and are asked to provide them. Assess how students provide adequate descriptions for complex images"
  Proposed: "Practical — Students are asked to code descriptions for a set of given charts and graphics. Assess how students code descriptions for complex images".
  Rationale: While providing descriptions for simple and functional images may be one of the developer tasks, providing descriptions for complex images may be out-of-scope for many developers.
• [Module 4] [Topic Simple Tables] -- Reworded ideas for assessment:
  "Practical — A simple table is presented to Students. They are asked to identify the table's headers and to code them using the `th` element. Assess students’ understanding of the `th` element."
• [Module 4] -- Clarifying assessment for module:
  "Short Answer Questions — Students are directed to a web page where there are several tables. Then they are asked to use an accessibility evaluation extension to provide all table header and data cells they have found. Assess how students analyze if a table is coded appropriately to reflect its structure."
• [Module 4] -- Added idea to assess knowledge for module:
  "* Practical — Students are guided to use mechanisms that assistive technologies provide to move to next and previous table, to move between table cells, and to show all the tables of a web page in an isolated list. Assess students’ knowledge of mechanisms of assistive technologies to move through tables."
• [Module 5] [Topic Time Limits] Added assessment for topic for developers to identify mechanisms to stop, adjust, or extend time limits:
  "Practical — Students are asked to find several websites where mechanisms to stop, adjust, or extend time limits are in place. They are asked to reference the website or functionality where those mechanisms are found. Assess how students identify mechanisms to stop, adjust, or extend time limits."
• [Module 5] -- Re-scoped assessment for module:
  “Practical — Students are guided to fill in form controls using mechanisms that assistive technologies provide to move to next and previous form control or to show all form controls in an isolated list. Assess students' knowledge of mechanisms of assistive technologies to interact and fill in form controls.”
• [Module 6] [Topic Focus and Keyboard Management] -- Reworded assessment:
  "Short Answer Questions — Students are asked to provide all the possible values for the `tabindex` element and to explain what each of those values means. Assess students' knowledge of the attribute `tabindex` and its values."
• [Module 6] [Topic Live Regions and Notifications] Added assessment around priority levels:
  "Practical — Students are presented with different types of alerts. They are asked to indicate their priority level and to code them appropriately. Assess students' understanding of the attribute `aria-live` and its values `polite`, `assertive`, and `off`."
  • Do you agree with these additions?
  • Do you have any further comments?
  • Any suggestions on how to better communicate these changes?

    Details

    Responder	Comments
    Daniel Montalvo
    Gerhard Nussbaum	I'm ok with the changes. Table navigation with screenreaders is a bit comprehensive - but it's good to know for understanding tables.
    Dónal Fitzpatrick	I think these additions are excellent and could easily envisage including them in various modules of the degree programmes on which I teach.
    David Sloan	I agree with all the proposed additions/edits with the following exceptions: [Module 4] -- Clarifying assessment for module: I'm unclear about this text "they are asked to use an accessibility evaluation extension to provide all table header and data cells they have found". An accessibility evaluation tool would find and identify header and data cells, but would not provide them, so should the text be edited to reflect this? [Module 4] -- Added idea to assess knowledge for module: Suggest rewording last sentence of practical description to: "Assess students’ knowledge of mechanisms of assistive technologies to move through table content and between tables." [Module 5] [Topic Time Limits] - Suggest extending the description to encourage students to evaluate the *quality* of the solution (i.e. go beyond identifying that the mechanisms exist, but assess how well they meet accessibility requirements. This could for example include poorly implemented timeout warning dialogs) [Module 6] [Topic Focus and Keyboard Management] Suggest rephrasing "Students are asked to provide all the possible values for the `tabindex` element". Tabindex can take a large number of values, but all but two ("0" and "-1") are unhelpful for accessibility. So the exercise should focus on the *meaningful* values, not all possible values? Also, in this sentence, replace "element" with "attribute".

The following is a list of added or reworded teaching ideas based on EOWG's thorough review feedback.

• [Module 4] [Topic Table Summaries and Descriptions] [3rd bullet] -- Qualified teaching ideas about the summary element:
  "[...] Emphasize that it is obsolete according to the HTML5 specification and should, therefore, be used with caution. [...]"
• [Module 5] [Topic Time Limits] -- Added teaching idea for topic around different types of time limits:
  "Demonstrate examples of different types of time limits, such as banking site timeouts, ticket purchasing countdowns and timeouts, assessment timings, inactivity timeouts, or chatbot timeouts."
• [Module 6] [Topic Accessible Names and Descriptions] [Third bullet] -- Added "[...] Show several browsers and examples of how they may render different accessible names from the same coding pattern. [...]".
  • Do you agree with these additions?
  • Do you have any further comments?
  • Any suggestions on how to better communicate these changes?

    Details

    Responder	Comments
    Daniel Montalvo
    Gerhard Nussbaum	I'm ok with the changes.
    Dónal Fitzpatrick	Whilst I generally agree with these additions I feel that some more thought needs to go into the recommendations in respect of bullet-point 1 above. If the summary is obsolete, should it be included at all? If we are noting its obsolescence, should the bullet point then also include recommendations for its replacement with newer techniques.
    David Sloan	I agree with these additions, with one additional thought: [Module 6] [Topic Accessible Names and Descriptions] I wonder if it would also be appropriate for the exercise to include how different AT announces the same coding patterns, to show how there might be differences there too?

Please provide any other additional comments or suggestions you may have before bringing the curriculum back to the whole EOWG for Butterfly Approval (Approval to publish) survey.

Details