Skip to content

schedule

Jump to bottom
daniel-montalvo edited this page Feb 16, 2022 · 62 revisions

Schedule and changelog for work on the WAI Curricula foundation, developer, designer, and Writer Modules through June 2022 (WAI-Guide end).

Priority: Writer Modules

Table of Contents

Writer Modules

Schedule

  • February - March -- TF works on first ideas about Writer Modules.
  • Late March -- Survey for TF and EOWG on overall curricula structure. Will contain proposed module titles, learning outcomes for module.
    Ideally we agree on overall structure before fleshing out modules and topics.
  • Late April -- First complete draft for TF and EOWG survey.
  • Early June -- Thorough TF and EOWG review.

Designer Modules

Designer Modules as agreed in January 2022 survey

Schedule

  • Late February -- agreed on overall structure (modules coverage and learning outcomes for module).
  • Mid March: Flesh out first 2-3 modules and send them for TF review.
  • Late March -- flesh out remaining modules and send for TF review.
  • Late June -- Sent first complete draft to TF Starfish Review (rest of EOWG welcome)
  • Mid October -- final draft for thorough review.
  • November -- polishing of whole curriculum and final approval.
  • December -- approval to publish and publication of resource.

Developer Modules

Developer Modules as agreed in Weekly Survey for December 13.

January 26 2021

List of changes after late December curricula survey.

See current preview at Developer Modules Editor's Draft

Overall Changes

  • Introductory bullets -- Changed "demonstrate how people with disabilities use ..." to "how people with disabilities rely on".
    Rationale: People with disabilities often do not use these coding techniques directly, but rely on them to better interact with the Web
  • Learning outcomes
    • Changed "code" or "mark up" to "write code" or "write markup".
      Rationale: These words can be both a name and a verb, thus being ambiguous.
    • Clarified "markup" and "code"" in learning outcomes
      "markup" refers to only HTML and WAI-ARIA, whereas "code" refers to coding abilities involving CSS and/or JavaScript.
    • Changed "recite related requirements (...)" to "describe related requirements (...)".
      Rationale: "Describe" better communicates the learning objective.
  • Topics to Teach -- Changed "Topics to support the teaching sequence" to "Topics to achieve the learning outcomes".
    Rationale: The latter better communicates the objective of this section.
  • First "expand all" button moved before the heading "Competencies" to avoid confusion as to which section this button expands/collapses.
  • Teaching Ideas
    • Qualified expression "speech and mainstream technologies" where appropriate to better reflect assistive technologies and adaptive strategies.
    • Some references to Stories of People with Disabilities now references to the overview page on How People with Disabilities Use the Web, as specific references to stories were misleading.
  • Ideas to Assess Knowledge
    • General pass on passive voice to active voice. For example: "Students are presented with (...)" -> "Give students (...)"
    • Changed "guide" to "supervise".
      Rationale: better align wording with the purpose of these ideas.
  • Reordered teaching resources for all modules -- most relevant at the top, repeated ones at the end.

Curricula Overview Page

  • General pass to tighten and tersify.
  • Changed titles to better communicate contents in each of the sections: Now we have:
    • "Using the Curricula" (previously "Overview")
    • "Contents"
    • "Structure and Terminology"
    • "Essentials for Teaching Accessibility" (previously "Tips")
  • Added information about specific modules according to the different situations proposed under bullets in "Using these curricula" (this was previously in a paragraph under the older "How to use" section)
  • Changed headings to list under "Essentials for teaching accessibility"
  • Under "Essentials for teaching accessibility", fourth bullet -- Added "Approach accessibility holistically. -- Communicate accessibility as part of the broader umbrella of inclusion and diversity [...]."

Developer Modules Overview Page

  • Introduction -- Reordered two first paragraphs for clarity.
  • Introduction, second paragraph, two and third bullets -- Added "demonstrate and explain" and "teach" respectively to encourage a practical approach for courses resulting from these modules.
  • Prerequisites from students
    • Changed explanatory paragraph to: "The developer modules are designed for students who have achieved the learning outcomes from the following subset of Foundation modules", as agreed in EOWG Meeting Jan 8.
    • Added explanatory sentences for each of the listed modules and module topics.
  • Modules
    • Changed title to simply "modules" as we are not using the words "curriculum" and "curricula".
    • Added explanatory sentences for each of the listed modules and module topics.

Module 1: Page Structure

  • Changed "processing" to "interpreting" for clarity in
    • Learning Outcomes for Module -- "write markup for page meta-information to facilitate identification and interpretation"
    • Learning Outcomes for Topic "Page Orientation and Navigation" -- "write markup for the primary language of web pages to allow correct interpretation by assistive technologies"
  • Added "and style" to "mark up and style content so that it has a distinguishable focus indicator"
  • Changed name for topic "Page composition" to "Page Orientation and Navigation"
  • Added references to WCAG 2 Success Criterion 2.4.4 Link Purpose (In Context) in "Competencies" section.

Module 2: Menus

  • Qualified learning outcomes for module to better reflect resizing and communication of state:
    "write code for menus to resize depending on different viewport sizes" and
    "write code to communicate the state of fly-out menus to people using different assistive technologies and adaptive strategies"
  • Topic "Menu structure"
    • Teaching ideas, first bullet, -- Added references to navigational regions and headings: "Students identify the regions of the page that contain the menus and mark them up using navigation regions or headings where appropriate. Assess students' use of the HTML element `nav` or headings where appropriate to mark up menus"
    • Teaching ideas, third bullet -- Added specific references to text within the HTML element `a`:
      " "Practical — Students are presented with a menu and are asked to label its menu items."
  • Topic: Application Menus
    • Qualified scenarios to use application menus.

Module 3: Images

  • Changed from "images and graphics" to "images" where appropriate for tersification.
  • Topic: Simple Images
    • Clarified introductory paragraph.
      "Demonstrate how text alternatives allow people to access information included in images. Explain how text alternatives can be presented in different ways, for example visually in different text sizes, through text-to-speech, as braille, and as symbols. Explain different coding techniques to provide text alternatives for images."
    • Clarified teaching idea, third bullet --same image in different context may have different (or no) text alternative.
      "Show different examples of informative images (including images of text) and contrast them with decorative images. Explain how context can affect the meaning of the same image. Emphasize how each context may require a different text alternative, including an empty text alternative when the image is decorative. (...)"
  • Topic: Complex Images
    • Qualified use cases where alt can be used in addition to figcaption, both in learning outcomes and teaching ideas.

Module 4: Tables

  • Topic: Simple Tables
    • Last teaching idea split into two separate ones for clarity: one deals with alternative table renderings and the other recommends not to use layout tables.

Module 5: Forms

  • Topic: Controls and Labels
    • Teaching idea, first bullet: Clarified scope for labels that are shown on hover or focus but need to be permanently available for assistive technologies.
      "(...) Explain the use of other explicit associations using the HTML attribute title, the WAI-ARIA attributes aria-label or aria-labelledby, especially for cases where the label is only shown on hover or focus but still needs to be associated for assistive technologies. (...)"

Module 6: Custom Widgets

No specific changes apart from those mentioned in the general section.

Module 7: Rich Applications

  • Topic: Structure and Relationships
    • Removed "which may each be individual widgets" from introductory paragraph.
    • Added explicit references in learning outcomes to updating widgets and to the types of widgets in use.
      "write code for updating applications and dynamically generated content with appropriate markup structures and semantics, including:"
      (...)
      "widgets, including menu bars, form controls, and custom widgets"
    • Teaching ideas, first bullet -- Changed example widgets. Now using "menu bar, main text area, or toolbar" to better point to different application widgets.
    • Teaching ideas, fourth bullet -- Changed to "different mechanisms to hide content from view, from the accessibility tree, or from both (...)" as opposed to only discussing the attribute aria-hidden.
  • Topic: Keyboard and Focus Interactions
    • Learning Outcome -- Added "ensure that the focus is placed appropriately when inline error messages are generated for application form controls"
    • Teaching ideas, fourth bullet -- Expanded on specific responsibilities per role, as previous wording was not clear enough about them.
      "(...) Mention that coding keyboard and focus interactions is a developer's responsibility, whereas defining such interactions is a designer's responsibility. (...)"
    • Teaching ideas, fifth bullet -- Clarified scope: "mechanisms to communicate information about available keyboard shortcuts (...)".
    • Teaching Ideas, sixth bullet -- Clarified sentences about focus management within modal dialogs.
      "Emphasize how focus remains within the boundaries of the dialogs when they have been coded appropriately. Explain that the contents that are not part of the modal dialog should not be focusable as long as the modal dialog is displayed. (...)"
  • Topic: Concurrent Notifications
    • Learning Outcomes: added explicit references to live region roles alert, status, role, marquee, and timer.
    • Teaching Ideas, first bullet -- Added explicit mentions to "requesting for new data" and "an address lookup", to better illustrate live regions indicating progress of change.
    • Teaching Ideas, second bullet -- Added specific mentions to "confirmation messages" and "progress bars to indicate timeouts" to better reflect high priority notification warnings.
    • Ideas to AssessKnowledge, second bullet -- Clarified scope. "messages for assistive technologies to indicate what is the currently loaded view".

16 October 2020

Task Force discussing changes based on

Preview: https://deploy-preview-273--wai-curricula.netlify.com/curricula/developer-modules/

General

  • 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", as it better reflects the assessment type.
  • Changed "competencies" section in several modules for consistency.

Module 1: Structure and Semantics

  • Topic: Section Headings
    • Added learning outcome: "explain how headings provide a summary of page content that can be navigated by assistive technologies such as screen readers"

Module 2: Navigational Menus

  • Added learning outcome for module: "identify and code appropriate keyboard controls for interactive menus"

Module 3: Images and Graphics

  • 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: Tabular Information

  • Added learning outcome for module: "summarize related requirements for authors and designers to provide information about the relationships between header and data cells"
  • Topic: Simple tables
    • Reworded learning outcome: "define simple tables as those which contain one row or column header"
    • Added learning outcome for topic: "summarize related requirements for designers and content authors to use CSS techniques for avoiding table layout designs"
    • 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."
  • Topic: Complex tables
    • Reworded learning outcome for topic: "define complex tables as those which contain multiple row and column headers"
  • Added further explanations for scope: "Demonstrate the use of the HTML attribute `scope` and its values `row`, `col`, `rowgroup`, and `colgroup`, to code the direction of the headers. Explain that these values indicate headers for row, column, group of rows, and group of columns respectively."
  • Topic: Table Summaries and Descriptions
    • Qualified uses for the attribute summary in learning outcomes: "the HTML attribute `summary` (recommended for fallback purposes)"
    • Qualified teaching ideas about the summary element: "[...] Emphasize that it is obsolete according to the HTML5 specification and should, therefore, be used with caution. [...]"
  • 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."
  • 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: Forms and Input Elements

  • Added WCAG 2 Success Criterion 2.5.3 Label in Name to competencies for instructors.
  • Topic: Form Labels
    • Qualify uses for each of the elements and attributes mentioned in learning outcomes for topic:
      • "code labels and input field associations using:
  **** the HTML attribute `for` (when an explicit association is needed)
  **** the WAI-ARIA attributes `aria-label` or `aria-labelledby` (when the label text needs to be visually hidden)
  **** the HTML element `title` (when the label text needs to be visually hidden)"
    • Added learning outcome for topic: "explain how labels are used by users of voice control software to activate and interact with form controls"
  • Topic: Form Instructions
    • Added learning outcome for topic: “summarize related requirements for designers to provide mechanisms that consolidate already entered data”
  • 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."
    • 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."
  • Topic: Validation and Notifications
    • Added learning outcome for topic: “explain how each of these methods of notifications benefit people with disabilities”
  • 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: Custom Widgets

  • Topic: Keyboard and Focus Management
    • Added learning outcome for topic: “* summarize related requirements for designers to provide different choices for users when selecting options in complex widgets, such as typing to narrow results”
    • 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."
  • 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`."

Previous work and surveys:

  • Survey on outline of second curriculum: Survey January 29-4 February. Discussion February 7th.
  • Implementation of suggestions from first round of discussion (learning outcomes for modules and topics). Survey 2-9 March. Discussion March 13.
  • April 14: first Task Force meeting. Discussing timeline proposed and next steps
  • April 21: a closer look at learning outcomes for the modules and topics in the first draft. Is there anything missing? Anything that should be included?
  • April 28: (no teleconference). A closer look at learning outcomes for the modules and topics in the first draft. Survey results.
  • May 5: A closer look at the teaching ideas for topics. Is there anything missing? Anything we should include?
  • May 12: (no teleconference). A closer look at ideas to assess knowledge for topics and modules. Survey results.
  • Survey 15-22 June on complete drafts for modules 1-3.
  • June 23: Discussing results of survey on modules 1-3.
  • Survey 22-29 June on module 4-6.
  • June 30: Discussing survey results on modules 4-6 and remaining issues.
  • Early October: Whole curricula sent for all EOWG review.
Clone this wiki locally