W3C

Site Navigation

Nearby

Results of Questionnaire [Curricula] Review of changes before Butterfly Approval

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: dmontalvo@w3.org,shadi+eosurvey@w3.org

This questionnaire was open from 2020-12-02 to 2020-12-18.

14 answers have been received.

Jump to results for question:

  1. Introduction
  2. General Changes
  3. [New] Module 7: Rich Applications
  4. Changes in Module 1: Page Structure
  5. Changes in Module 2: Menus
  6. Changes in module 3: Images
  7. Changes in module 4: Tables
  8. Changes in module 5: Forms
  9. Changes in module 6: Custom Widgets
  10. Changes in Developer Modules overview page
  11. Changes in Curricula on Web Accessibility overview page
  12. Additional comments

1. Introduction

This is another thorough review survey to discuss changes resulting from:

Preview with proposed changes is at: https://deploy-preview-273--wai-curricula.netlify.com/curricula/developer-modules/

Main changes include:

  • Rewritten overview page based on requirements analysis for supporting materials
  • Added Module 7: Rich applications, to better clarify scope for accessible rich applications
  • Streamlined learning outcomes to better relate to accessibility requirements
  • Define accessibility related terms such as simple and complex images and tables consistently throughout the resource
  • Qualify specific situations where several techniques can be used to provide labels or descriptions, such as alternative texts for images, table descriptions, or labels for forms and controls
  • Renamed some modules to better reflect their actual content
  • Renamed topics and reorganized their contents to facilitate teaching sequence

The following questions will guide you through the most significant changes. Please provide any specific feedback you have, especially if you don't agree with the proposed changes.

Details

Responder Comments
Hidde de Vries
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen I agree with the changes
Andrew Arch
Gerhard Nussbaum
Carlos Duarte
Howard Kramer
Kevin White Given the range of changes indicated it would have been useful to have a diff or two linked in the survey - I was left re-reading the whole of previous sections that had been previously reviewed with little memory of what was there previously. This was most problematic in the changes to existing modules.

Actually, I am stopping at Module 2 - I am concerned I am going over previous ground without knowing what has changed. If you can provide diffs I will look at it :)
Mark Palmer
Sarah Lewthwaite
David Sloan Due to limited time, I focused most of my review attention on Modules 6 and 7, so my comments for the other modules are from a less thorough review. Overall, I think the additional detail provided for each module has really enhanced their quality as references for curriculum design.
Estella Oncins I agree that 'recite' might not be the best term to use. According to Bloom's taxonomy 'recite' belongs to the "remember" domain which other verbs might be define, identify, indicate, label, list, match, memorize, recall or recognize would apply. If we move to the "understand" domain then verbs such as compare, classify, describe, discuss, explain, give examples, interpret, paraphrase, predict, present, report, rewrite, summarize would apply.

Same with "Topics to support the teaching sequence" it might led to a confusion as in other parts of the module the term "sequence" is used technically. Maybe better "Topics to support/achieve the learning outcomes".

Under "Teaching Ideas for Topic", "Optional ideas to teach the learning outcomes" all bullets start with a capital letter, maybe it should be changed into a lowercase as in all other sections.
Shawn Lawton Henry I commented on two pages. I pass on commenting on the others, and appreciate the attention and expertise of the rest of the Task Force and Working Group on developing and reviewing this material.

2. General Changes

The following is a list of general changes affecting the whole resource.

  • Changed introductory paragraph at the top of each of the modules
    from "Courses based on this module:"
    to "Courses based on this module should:"
    Example at Introduction for module 1
    Rationale: This clarifies that the below bullets are expected goals or objectives for the courses and not actual courses that we are listing.
  • Changed order of bullets in the introductory paragraphs for each of the modules
    Example at Introduction for module 1
    Rationale: New order better reflects how accessible coding benefits people with disabilities.
  • Changed "summarize" to "recite" when providing sign posting references to other roles responsibilities in learning outcomes.
    Rationale: It better communicates the importance of knowing such requirements, instead of just summarizing them.
  • 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.

Is there anything from these changes that you would disagree with?

Please provide comments on the below box or open a GitHub issue on general changes

Details

Responder Comments
Hidde de Vries
Sylvie Duchateau
Dónal Fitzpatrick I note an inconsistency in the bullet points in Module 1. The first two use "demonstrate" the third "explain". A suggestion might simply be to use "Demonstrate and explain" across all three points (and in other modules). Rationale: This covers both theoretical and practical knowledge and suggests that students must not only understand the coding concepts, but demonstrate their use. This rationale is also supported by many of the suggested practical activities throughout the various modules.

I disagree with the choice of "recite" as an alternative to "summarise"."recite" suggests to me that students learn this information by rote and then simply regurgitate it. It reminds me of people being forced to simply learn and recall poetry to be given back verbatim in a class situation. I am not convinced that this is the appropriate term. For example: in the "Section Headings" of Module 1: I feel that it is less important for students to recite related requirements for authors and designers to provide meaningful texts and distinguishable styles for headings" than to relate their knowledge from this topic to others.

With regard to the "Change explanatory sentence at the "topics to teach level" ":
The current wording implies that all topics are required. I think that the wording in the "rationale" above excellently captures the salient point here and perhaps this phrase could be incorporated somewhat.

In the topic "Section Headings:
Practical — Students are presented with headings that do not describe the sections they entitle and are asked to replace the heading’s text..."


could I suggest a rewording here to replace "heading's text" with "textual content of the heading".
Laura Keen Looks good. I agree with the changes.
Andrew Arch I wasn't sure about 'recite' vs 'summarise' - but the logic make sense

Agree with everything :)
Gerhard Nussbaum I completely agree with it.
Carlos Duarte - I'm not sure about the "recite" change. To me recite implies committing to memory so that later it can be repeated word by word. I don't think we want to ask a developer to know, word by word, the requirements for designers, for example. I agree that summarising did not stress enough the importance of being aware of those requirements. But recite seems to me to be on the opposite end of the spectrum, and I believe something in between would be better. I would prefer to use "explain" because that would mean the student developer understood the requirements for designers, which is a lot better than reciting them (which does not imply understanding).

- Regarding the "Topics to achieve the learning outcomes" change. I prefer the suggested use of "Topics to achieve the learning outcomes". However, the current preview uses "Topics to support the teaching sequence". This implies there is a sequence, but that sequence is not clearly presented.
Howard Kramer No disagreements.
Kevin White * "recite" isn't really the right word. I think the phrase is that "students should know related requirements..." but that doesn't quite fit with the opening statement for the lists. Perhaps, "describe" would be good or maybe better would "detail".

* "Topics to achieve the learning outcomes" seems to be "Topics to support the teaching sequence". The former is certainly better than the latter.

* [Minor] The assessments include the phrase "Students are guided to use..." it seems a bit... off. If it is an assessment students wouldn't be guided in anything. Would the be asked to demonstrate?
Mark Palmer I'm somewhat intimidated by "recite". Feel "communicate" may be softer.
Sarah Lewthwaite Bullet #3: move from 'summarize' to 'recite': From Bloom's Taxonomy/educational perspective 'summarizing' is indicative of higher order learning - understanding and synthesis, whereas 'recite' suggest a rote learning/memorising/repetition or plain 'read-out' that is very basic. I appreciate the rationale, and it may be necessary to keep as is, however, would 'detail', 'convey all' or 'articulate all' work better? E.g. "Convey all related requirements for authors and designers to provide meaningful texts and distinguishable styles for headings".

I agree with all other points.
David Sloan I support the general changes with one minor exception: I'm not sure "Recite" is the correct verb to use for the cognitive skill of being able to remember the responsibilities of other roles. "Recite" specifically implies reading them aloud from memory. I suggest "Define" or "Identify" as better options.
Estella Oncins Not sure if "demonstrate how people with disabilities..." is the correct term in this context, demonstrate implies that students "apply" the knowledge acquired. Is it expected? Or are they expected to explain/describe how people with disabilities use headings or rely on semantics? This is just a question.
Shawn Lawton Henry

3. [New] Module 7: Rich Applications

Module 7: Rich Applications has been added to clarify scope for rich applications, such as Single Page Applications (SPA), and others generated by JavaScript.

This is a thorough review of this module.

What you're reviewing is everything in the final draft.

  • This is EOWG's pre-publication review, our internal "last call".
  • Review and comment on anything and everything, including copy-editing as needed.
  • Speak now or forever hold your peace.
    We hope there will not be any more new comments after this review.

For more details about EOWG's review process, check Review Stages and Levels

Please provide comments in the below box or open a GitHub issue about module 7

Details

Responder Comments
Hidde de Vries added comments in GitHub: https://github.com/w3c/wai-curricula/issues?q=is%3Aissue+is%3Aopen+%22Module+7%22+author%3Ahidde
Sylvie Duchateau
Dónal Fitzpatrick 1. I suggest re-wording the bullet points in the introduction of the module to include "demonstrate and explain" as the learning objectives and content seem to do both.

2. See comments in respect of my answer in 2 above regarding the use of the word 'recite'.

In the third, fourth and fifth learning outcomes, I would suggest replacing "code" with "apply coding techniques to...". Indeed, as an aside, this wording might be considered for other modules also. The sixth again refers to 'recite' which is not a word I feel best fits the learning objective.


In all sections, the learning outcomes should, in my view, be looked at in the context of my suggested rewording from earlier in both this section of the questionnaire and 2 above. I note that the learning outcomes use excellent terms such as "describe", "ensure that" etc. I find these to be excellent and applaud their inclusion.


Laura Keen No comments.
Andrew Arch I like this - while not my area of expertise, it all makes sense.
Gerhard Nussbaum I completely agree with it. This module includes all relevant and neccessary topics.
Carlos Duarte - In the first bullet of the introduction, what does it mean "demonstrate how people with disabilities use structures"? Removing "use structures," would make the whole sentence clearer.

- The "Expand All Sections" and "Collapse All Sections" buttons are being applied to all sections inside the module and not just the subsections of the section they are presented in. Given they appear below the "Competencies" section I was expecting them to apply just to the "Students" and "Instructors" subsections. But they are expanding and collapsing also the "Topics to Teach" subsections. (this applies to the other modules also)
Howard Kramer
Kevin White * ", which may each be individual widgets" - not sure what this adds other than a bit more of a challenge to parse the sentence. I think it could be better explored in the detail than introducing it in the topic introduction.

* There seems to be a lot of repeated content between Structure and Relationships and Module 1. I am not sure what the learning outcome really is or how this relates to RIA? Not saying that it isn't necessary just a bit unclear as to why it is being repeated.

* First teaching idea seems to be using a disclosure widget as the example for navigation. I wonder if this is too limiting and doesn't illustrate how structural elements and regions help navigation.

* Use of aria-hidden - I have seen this being used to present two different sets of content; one visually but not in the accessibility tree, and one non-visually but in the accessibility (using e.g. sr-only CSS). Worth mentioning?

* Structure and Relationships ideas to assess asks students to code for updates, but the learning outcomes don't actually cover this - there may be a need for something specific along the lines of "code applications to update structure and/or semantics in response to user action"

* Topic: Keyboard and Focus Interactions - is this more about "Keyboard and Focus Management"?

* Is there a need to add a learning outcome around focus management for inline error messages on form submission?

* "Mention that setting focus to the most relevant place in a rich application is a shared responsibility among different team members: designers and developers" - It may not be apparent what each responsibility is. Maybe something more explicit like (sorry, wording may need work) "Outline the designer responsibility to describe the next logical interaction and developer responsibility to ensure that focus is managed accordingly".

* "Demonstrate the use of mechanisms to obtain information about the available keyboard shortcuts" - is this about demonstrating ways to communicate this rather than ways that it might be found? As it is written it hints that there are some standard ways that you can find out about keyboard shortcuts in applications. New one on me if there is such methods?

* "Explain that specific focus treatment should be applied to the contents that are not part of the modal dialog as long as it is displayed so that they are not reachable using the keyboard" - not sure what this is getting at.

* "identify and code status messages that may not originate from any particular widget or part of the application" - not sure why or where such messages would come from then?

* Is there something missing in notifications to discuss the different specialized live region roles such as log, status?

* Not sure the first teaching idea in notifications is that great. If the goal is to explore live regions being used to indicate progress of change then I think an example like an address look up or making a data request from another source would be more appropriate.

* The second teaching idea in notifications mentions modal windows and alerts on warnings which would require interactions. I don't know that I would use a live region in this case as I don't just want the user to be informed, I would need them to do something - so it would be a modal dialog with an active choice. What about confirmation messages as a teaching idea or a chat bot... oh, those are all the rage!

* Again, not sure I would code a quit prevention using a live region - I would do it with a modal and focus management. What about students coding a progress bar?

* Not sure what the second assessment idea is at all


Mark Palmer
Sarah Lewthwaite On readability of 'Prerequisites for Student'. The opening sentence is difficult: "Students of courses based on this curriculum are expected to have achieved the following learning outcomes from the prior Foundation modules". Is there an option to consider how 'courses based on this curriculum' could instead specify the course/curriculum in question, with similar edits made across 'Prerequisites for Student' sections? This may help to clarify the sentence for readers.
David Sloan Overall, I think this module draft does a very good job of building on previous modules, without unnecessary overlap.

Minor suggestions:
* in Topic: Structure and Relationships, Teaching Ideas for Topic. Suggest extending the description of the aria-hidden idea to cover the difference between visually hidden, hidden from the accessibility tree *and focus order*, given that focus management is a distinct thing and something that is not in the accessibility tree could still be focusable.
Estella Oncins Same issues as reported in the previous points.
Shawn Lawton Henry

4. Changes in Module 1: Page Structure

Please have a look at module 1 page structure, specifically focusing in the following:

Is there anything from these changes that you would disagree with?

Please provide comments on the below box or open a GitHub issue

Details

Responder Comments
Hidde de Vries Reviewed all, looks good!
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen No comments.
Andrew Arch Looks good
Gerhard Nussbaum I completely agree with it.
Carlos Duarte - I have concerns about 3 entries in the learning outcomes for module. First is the "mark up page meta-information to facilitate identification and processing". It is not clear to what "facilitate identification and processing" refers to. I'm identifying and processing what? Second is the "outline the benefits of using HTML native elements for compatibility with assistive technologies and adaptive strategies". There is an implicit comparison here between native elements and elements with ARIA and scripting. I think this should be made explicit. Third is the "mark up content so that it has a distinguishable focus indicator". I don't think this belongs in this module. The module is about page structure, and I believe this is not the appropriated place to talk about focus indicator, specially because most structures discussed in the module won't even be focusable.

- In the "Section Heading" topic, second item of the learning outcomes list, role equals heading is ending with a single quotation mark, when it should be a double quotation mark.

- In the "Sections of Content" topic, last item of the teaching ideas list, the last sentence needs updating to "Examples of how to code quotes are presented in the WAI tutorials on Quotes."

- In the "Sections of Content" topic, last item of the ideas to assess knowledge list, there are two consecutive commas following the word "paragraphs"
Howard Kramer Suggested change (not crucial)
mark up content so that it has a distinguishable focus indicator
to
mark up [and style] content so that it has a distinguishable focus indicator

Any thoughts on directing student pre-reqs to wai tutorials on page structure to tutorials (https://www.w3.org/WAI/tutorials/page-structure/) instead of the Whatwg source?
(see other changes/suggestions in github)
Kevin White * "explain how headings, including their rank levels, are used by different types of assistive technologies, such as text to speech, and adaptive strategies, such as custom stylesheets, to allow people with disabilities to understand and navigate the content" - too many 'such as' structures. Possibly "explain how headings and their rank levels are used by different types of assistive technologies and adaptive strategies, such as text to speech or custom stylesheets, to allow people with disabilities to understand and navigate content". Of just dump the 'such as ..' entirely.

* "explain how properly coded page regions can be presented in different ways, including being read aloud using text-to-speech technologies, with custom or without any styling, and in different screen and text sizes" - this is used in a couple of the learning outcomes. I think I get what it means but I might struggle to actually teach to that. Might benefit from a clearer outcome?

* "code the primary language of web pages to allow correct processing by assistive technologies" - correct processing or correct pronunciation?

* "code distinguishable focus indicators, for example by using the CSS :focus selector" - this seems out of place here but I am not sure where else it might go? - actually, reading the topic introduction I am beginning to think that the topic title could benefit from a change. It seems to be a catch all around orientation and navigation rather than composition. I think of 'composition' as the action written word.
Mark Palmer
Sarah Lewthwaite No comments.
David Sloan This looks good to me. One minor suggestion would be to include, somewhere in Page Regions or Page Composition (or both), the relationship of responsive design to structure and order. The intention would be to reinforce the idea that visual layout may change at different viewport sizes, but underlying page composition generally does not, except when using techniques like menu buttons for nav menus.
Estella Oncins Same issues as reported in the previous points.
Shawn Lawton Henry

5. Changes in Module 2: Menus

Please have a look at module 2 Menus specifically focusing on the following:

Is there anything from these changes that you would disagree with?

Please provide comments on the below box or open a GitHub issue

Details

Responder Comments
Hidde de Vries [developer hat on]

Generally, what I miss in this module is a clear explanation of whether and when to use ARIA-style menus. If I understand it correctly, most menus on websites are not application menus and should not be coded as such, but from this module it looks like they are a good choice. Would be good to have a examples of application menus vs not application menus. I feel most developers these days see what they're coding as an “application”, but this may be a different categorisation than what we mean in ARIA.
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen No comments.
Andrew Arch Agree with latest changes
Gerhard Nussbaum I completely agree with it.
Carlos Duarte
Howard Kramer [following in Learning outcomes is too vague]
recite related requirements for designers to ensure accessible behavior of menus
[does the following only refer to the "nav" element? Or also to list elements? Not clear]
Practical — Students identify the layers of the page that contain the menus and mark them up. Assess students’ use of the nav element to mark up menus.
[also found the following Ideas to Assess Knowledge for Topic unclear:]
Practical — Students are presented with a menu and are asked to label its menu items. Assess how students describe the topic and purpose of the menu item using text or graphics with their corresponding alternative texts within the HTML element a. [Is this a menu item that is using graphics? If it's text then there would be no use for alt text]
[Change:] code styles to make menus appear as needed, for example vertical, horizontal, or as breadcrumb trails
[to:] use styles to make menus display as needed, for example vertical, horizontal, or as breadcrumb trails
[tried to make these suggestions in github but I was getting text that did not match the original - strange and frustrating]
[the following is also vague and, again, I don't think the term "recite" is a good choice:]
recite related requirements for authors and designers to provide appropriate menu texts and styles
[could change to:]
implement related requirements for authors and designers to provide appropriate menu texts and styles
[but overall I find the above too vague]
[following under Teaching Ideas under Menu Styling should be changed:]
Explain that they need to be [marked up and styled] so that they are placed in the expected position within the page.
Kevin White Comments added into diff
Mark Palmer
Sarah Lewthwaite Across Module 2: to reiterate the point I made earlier regarding the move from 'summarize' to 'recite'. On the use of 'recite' across the Menus modules. Would 'detail', 'recall',' 'convey all' or 'articulate all' work better where 'recite' is currently used? From Bloom's Taxonomy/educational perspective 'summarizing' is indicative of higher order learning, understanding and synthesis, whereas 'recite' suggest a rote learning/memorising/repetition or plain 'read-out' is very basic.
David Sloan From a quick read, this looks good to me.
Estella Oncins Same issues as reported in the previous points.
Shawn Lawton Henry

6. Changes in module 3: Images

Please have a look at module 3 Images specifically focusing on the following:

  • Changed module and topic titles, as well as reorganized topic contents. Current proposal is:
  • Reworded learning outcomes for module.
  • Content related to images of text moved to topic "Complex Images" (was previously under topic "Simple Images")
  • Reworded learning outcomes, teaching ideas, and ideas to assess knowledge for topics "Text Alternatives", "Functional Images", and "Complex Images".

Is there anything from these changes that you would disagree with?

Please provide comments on the below box or open a GitHub issue

Details

Responder Comments
Hidde de Vries Great content, nothing to add!
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen I recently read: https://thoughtbot.com/blog/alt-vs-figcaption. The article enlightened me on the use of alt and figcaption together. As well as why it's a bad idea to have an empty alt within figure/figcaption. I wonder if we should cover this also.
Andrew Arch I'll still argue that "write adequate text alternatives for images" (Learning Outcomes) is not a Dev's job, but a content job - that does becomes clear in "Topic: Text Alternatives"

Agree with everything else :)
Gerhard Nussbaum I completely agree with it.
Carlos Duarte I don't disagree with any of the changes in this module, but I believe including an additional item in the "ideas to asses knowledge" for topic "Complex Images" would be beneficial. The item would be practical and focus on using SVG to provide graphics. Current ideas ask to have students coding descriptions and writing CSS. By "pushing" for having images in SVG we would be "pushing" for more accessibility.
Howard Kramer [change learning outcomes from:]
recite related requirements for content authors and designers to provide accessible images and graphics
[to:]
implement requirements for content authors and designers to provide accessible images and graphics
[still think the above is unclear]
[under Text Alternatives under Learning Outcomes for Topic change:]
code decorative images using empty text alternatives and using CSS so that they are ignored by assistive technologies
[to:]
code decorative images using the null text alternative and using CSS so that they are ignored by assistive technologies

[other changes entered in github]
Kevin White Comments added into diff
Mark Palmer
Sarah Lewthwaite Learning Outcomes: On the use of 'recite' across the Images modules. Would 'detail', 'recall',' 'convey all' or 'articulate all' work better where 'recite' is currently used? From Bloom's Taxonomy/educational perspective 'summarizing' is indicative of higher order learning, understanding and synthesis, whereas 'recite' suggest a rote learning/memorising/repetition or plain 'read-out' is very basic.
David Sloan From a quick read, this looks good to me.
Estella Oncins Same issues as reported in the previous points.
Shawn Lawton Henry

7. Changes in module 4: Tables

Please have a look at module 3 Images specifically focusing on the following:

Is there anything from these changes that you would disagree with?

Please provide comments on the below box or open a GitHub issue

Details

Responder Comments
Hidde de Vries Again, nothing to add, these rewordings make it much clearer.
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen I agree with the changes.
Andrew Arch Agree with latest changes
Gerhard Nussbaum I completely agree with it.
Carlos Duarte - This module makes use of a concept that I haven't found in other modules when itemising assistive technologies: "provided by speech and mainstream technologies". I have to say I don't really know to what you are referring to when using "mainstream technologies" in this context. (it also appears in the Forms module)

- In the "Simple Tables" topic, the last item in the "Teaching Ideas" list is about different concepts: alternative rendering of data tables, and layout tables. I suggest to split it into 2 items in this list.
Howard Kramer [change:]
recite related requirements for authors and designers to provide information about the relationships between header and data cells in complex table cells
[to:]
implement related requirements for authors and designers to provide information about the relationships between header and data cells in complex table cells
Kevin White Comments added into diff
Mark Palmer
Sarah Lewthwaite Learning Outcomes/Complex Tables Learning Outcomes: On the use of 'recite' across the Tables modules. Would 'detail', 'recall',' 'convey all' or 'articulate all' work better where 'recite' is currently used? From Bloom's Taxonomy/educational perspective 'summarizing' is indicative of higher order learning, understanding and synthesis, whereas 'recite' suggest a rote learning/memorising/repetition or plain 'read-out' is very basic.
David Sloan From a quick read, this looks good to me.
Estella Oncins Same issues as reported in the previous points.
Shawn Lawton Henry

8. Changes in module 5: Forms

Please have a look at module 5 Forms specifically focusing on the following:

  • Changed module and topic titles, as well as reorganized topic contents. Current proposal is:
  • Reworded learning outcomes for module.
  • Content moved to topics "Instructions" and "Notifications" (was previously under topic "Time Limits" now removed).
  • Reworded learning outcomes, teaching ideas, and ideas to assess knowledge for topics "Control Labels", "Instructions", and "Notifications".

Is there anything from these changes that you would disagree with?

Please provide comments on the below box or open a GitHub issue

Details

Responder Comments
Hidde de Vries One minor thing: I saw 'HTML element title' as a way to label form controls in certain situations… personally I was not aware there are cases where it is good to use, might there be something we can link to that explains it? Editor's discretion, it shouldn't take any of the succintness of the resource away, describing this in too much detail may be beyond scope, but wanted to note it regardless.
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen I agree with the changes
Andrew Arch Is "recite related requirements for content authors and designers" in Learning Outcome's intended to include linear / single col forms for easier use by screen magnifier users in particular?

Agree with latest changes (subject to comment)
Gerhard Nussbaum Topic Instructions: aria-required is missing; just the HTML attribute required is mentioned
I completely agree with the rest of the modulet.
Carlos Duarte - In the topic "Controls and Labels", in the list "learning outcomes, in the last item, the work "labelling" should be "label"

- In the topic "Instructions", the last of the "learning outcomes" list has a nested list of what are requirements for content authors and designers. I don't think this level of detail is needed here, specially since it doesn't have related teaching ideas.

- In the topic "Notifications" I have a similar comment regarding the level of detail of requirements for content authors and designers.
Howard Kramer change all occurrences of 'recite' to 'implement'
Kevin White Comments added into diff
Mark Palmer
Sarah Lewthwaite On the use of 'recite' across the Forms modules. Would 'detail', 'recall',' 'convey all' or 'articulate all' work better where 'recite' is currently used? From Bloom's Taxonomy/educational perspective 'summarizing' is indicative of higher order learning, understanding and synthesis, whereas 'recite' suggest a rote learning/memorising/repetition or plain 'read-out' is very basic.
David Sloan From a quick read, this looks good to me.
Estella Oncins Same issues as reported in the previous points.
Shawn Lawton Henry

9. Changes in module 6: Custom Widgets

Please have a look at module 6 Custom Widgets specifically focusing on the following:

Is there anything from these changes that you would disagree with?

Please provide comments on the below box or open a GitHub issue

Details

Responder Comments
Hidde de Vries Under 'Learning outcomes' for role definitions, in 'WAI-ARIA authoring practices', Authoring and Practices should be capitalised.
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen I agree with the changes.
Andrew Arch Agree with latest changes
Gerhard Nussbaum "code accessible names for custom widgets by using HTML elements and attributes such as label title, and WAI-ARIA attributes such as aria-label and aria-labelledby" - a comma is missing between label and title

I completely agree with it.
Carlos Duarte - The first of the two items in the introductory list (i.e. the courses on this module should) doesn't seem to make much sense. People with disabilities don't use properties, states, focus interactions (at least) these to interact with custom widgets. The custom widgets are the ones that make use of properties, states, etc. to make the custom widgets accessible, so that people with disabilities can interact with them.

- In the "Accessible Name and Descriptions" topic, in the second item of the "learning outcomes" list, there is a comma missing between label and title
Howard Kramer change all occurrences of 'recite' to 'implement'
Kevin White Comments in diff
Mark Palmer
Sarah Lewthwaite Please see prior point raised on use of 'recite'. No other comments.
David Sloan From a quick read, this looks good to me.
Estella Oncins Same issues as reported in the previous points.
Shawn Lawton Henry

10. Changes in Developer Modules overview page

Please have a look at Developer Modules overview page specifically focusing on overall wording to outline the curricula contents.

Is there anything from these changes that you would disagree with?

Please provide comments on the below box or open a GitHub issue

Details

Responder Comments
Hidde de Vries Minor comment, editors discretion: feels like there are a lot of links on this page, maybe using a design patterns like the teasers on https://www.w3.org/WAI/planning-and-managing/ could help (Initiate, Plan, Implement, Sustain) for each of the modules.
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen I agree with the changes.
Andrew Arch Agree with latest changes
Gerhard Nussbaum I completely agree with it.
Carlos Duarte I find the current wording of the outline to be adequate. However, there are two aspects that could be improved:
1 - The order feels wrong. The introduction should begin with "This curriculum guides the creation of courses that" followed by the list of objectives. Only after that I feel what is now the first paragraph should be presented.
2 - The list of objectives for the courses feels very theoretical (introduce, demonstrate and explain). I feel we need some practical keywords, like "courses that teach accessible coding"

The introductory sentence of the section "Prerequisites for students" implies the presented list is a list of learning outcomes (because of the use of "following learning outcomes"), while it is in fact a list of topics. Removing the word "following" from the sentence should be enough to fix this.
Howard Kramer No disagreements.
Kevin White Looks good
Mark Palmer
Sarah Lewthwaite Please see prior point raised on use of 'recite'. No other comments.
David Sloan I have one suggestion for the description at the start of this page, in the "The curriculum guides the creation of courses that" list:
Include something like: "help developers understand the responsibility of other roles in making accessibility decisions necessary for developers to implement designs in an accessible way."
Estella Oncins Same issues as reported in the previous points.
Shawn Lawton Henry Potential misunderstanding of scope #303 https://github.com/w3c/wai-curricula/issues/303
Prerequisites for Students a bit annoying #302 https://github.com/w3c/wai-curricula/issues/302
minor and low text edits #301 https://github.com/w3c/wai-curricula/issues/301

11. Changes in Curricula on Web Accessibility overview page

Please have a look at Curricula on Web Accessibility page specifically focusing on the following:

  • Changes in structure resulting from EOWG discussions
  • Overall wording and tone

Is there anything from these changes that you would disagree with?

Please provide comments on the below box or open a GitHub issue

Details

Responder Comments
Hidde de Vries Really like how it has come together!
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen I agree with the changes.
Andrew Arch no disagreement
Gerhard Nussbaum I completely agree with it.
Carlos Duarte
Howard Kramer No disagreements.
Kevin White * "This resource provides a variety of teaching modules that you can combine to create different courses on web accessibility" - I would say it provides outlines for a variety of teaching modules. Just trying to ensure that people don't think these are the complete modules.

* "suitable for everybody in IT" - not sure about "IT", I know plenty of people who would benefit from this training who wouldn't consider themselves to be working in IT - content designers, service designers, graphic designers, interaction designers. They would say they work in "digital". This is probably one of those areas that there is a wide variety in.
Mark Palmer
Sarah Lewthwaite This looks good. An optional addition to 'Make it Accessible' section would be to state explicitly how important it is to show students what accessibility looks like by ensuring all presentations, teaching materials, exercises, assessments, and other student interactions are accessible. At the moment it says this is 'Good practice'. Being explicit about the pedagogic benefits in terms of demonstrating and modelling accessible practice and values may be helpful here.
David Sloan This looks good to me. My only concern to be sure we effectively communicate that these are module definitions, rather than ready-to-use teaching materials, so that we manage readers' expectations appropriately. So I wonder if in the Summary section, we should use the phrase "teaching module definitions"? I appreciate this issue has likely already been discussed and a resolution agreed, but I raise this anyway just in case we still need to consider it.
Estella Oncins Looks great!
Shawn Lawton Henry I think this page needs quite a bit of polishing.
I think the information is generally the right type of content and right level.

Some information needs to be moved around, headings more clear, etc. (For example:
* probably move some info from the Summary to "Accessibility Curricula Overview", and make that really an overview
* more clearly distinct headings than "Accessibility Curricula Overview" and "Overview on Curricula Modules"
* consider "resource" and clarifying "curricula" and "curriculum" as used
* consider "Universal Design"
* change "Foundation Modules suitable for everybody in IT"
* change "Author Modules (in progress) primarily related to content publishing"
...)

I will try to help in January.

12. Additional comments

Please provide any other additional comments or suggestions you may want to see addressed before we bring the curriculum back to the whole EOWG for Butterfly Approval (Approval to publish) survey.

Please provide comments on the below box or open a GitHub issue

Details

Responder Comments
Hidde de Vries I found two more very minor issues:

- in most modules, under “topics to teach”, the expand collapse all buttons are at the bottom of the section, while in the 'competencies' section, they are at the top, right underneath the introductory sentence
- for consistency: in module 1, it says ‘Topics to support the teaching sequence’ ending with a period, while before other lists on this page, these sentences end with a colon
Sylvie Duchateau
Dónal Fitzpatrick
Laura Keen This resource is well written and comprehensive. It will be a valuable tool for many organizations. Great work!
Andrew Arch Looking really comprehensive - excellent work :)
Gerhard Nussbaum Very good work!
Carlos Duarte
Howard Kramer Nice work.
Kevin White
Mark Palmer
Sarah Lewthwaite
David Sloan
Estella Oncins Real great work!
Shawn Lawton Henry

More details on responses

  • Hidde de Vries: last responded on 9, December 2020 at 15:13 (UTC)
  • Sylvie Duchateau: last responded on 11, December 2020 at 14:58 (UTC)
  • Dónal Fitzpatrick: last responded on 14, December 2020 at 14:43 (UTC)
  • Laura Keen: last responded on 14, December 2020 at 16:53 (UTC)
  • Andrew Arch: last responded on 14, December 2020 at 23:28 (UTC)
  • Gerhard Nussbaum: last responded on 15, December 2020 at 10:58 (UTC)
  • Carlos Duarte: last responded on 15, December 2020 at 20:10 (UTC)
  • Howard Kramer: last responded on 16, December 2020 at 02:07 (UTC)
  • Kevin White: last responded on 16, December 2020 at 09:46 (UTC)
  • Mark Palmer: last responded on 16, December 2020 at 16:22 (UTC)
  • Sarah Lewthwaite: last responded on 17, December 2020 at 14:57 (UTC)
  • David Sloan: last responded on 18, December 2020 at 10:58 (UTC)
  • Estella Oncins: last responded on 18, December 2020 at 18:22 (UTC)
  • Shawn Lawton Henry: last responded on 22, December 2020 at 22:46 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Eric Velleman
  2. Shadi Abou-Zahra
  3. Kazuhito Kidachi
  4. Sharron Rush
  5. Jedi Lin
  6. Mary Jo Mueller
  7. Vicki Menezes Miller
  8. Reinaldo Ferraz
  9. Bill Kasdorf
  10. Cristina Mussinelli
  11. Kevin White
  12. Kevin Rydberg
  13. Adina Halter
  14. Denis Boudreau
  15. Sarah Pulis
  16. Bill Tyler
  17. Gregorio Pellegrino
  18. Ruoxi Ran
  19. Jennifer Chadwick
  20. Sean Kelly
  21. Muhammad Saleem
  22. Daniel Montalvo
  23. Jade Matos Carew
  24. Sonsoles López Pernas
  25. Greta Krafsig
  26. Jason McKee
  27. Jayne Schurick
  28. Billie Johnston
  29. Michele Williams
  30. Shikha Nikhil Dwivedi
  31. Brian Elton
  32. Julianna Rowsell
  33. Tabitha Mahoney
  34. Fred Edora
  35. Rabab Gomaa
  36. Marcelo Paiva
  37. Eloisa Guerrero
  38. Leonard Beasley
  39. Frankie Wolf
  40. Supriya Makude
  41. Aleksandar Cindrikj
  42. Angela Young

Send an email to all the non-responders.

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 w3c/wbs-design or by mail to sysreq.