w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: dmontalvo@w3.org,shadi+eosurveys@w3.org,shadi+eosurvey@w3.org
This questionnaire was open from 2020-01-29 to 2020-02-07.
10 answers have been received.
Jump to results for question:
summary | by responder | by choice
Choice | All responders |
---|---|
Results | |
I reviewed it thoroughly. | 5 |
I skimmed it. | 4 |
I need more time, and will be able to review it by the date specified in the comment field. | |
I didn't get to it. | 2 |
Skip to view by choice.
Responder | Review level | Comments |
---|---|---|
Shawn Lawton Henry |
|
I'm not going to be able to get to this. I think others will have great input, probably better than I would on this now. :-) |
Sylvie Duchateau |
|
|
Eric Eggert |
|
I did a thorough skim. |
Kevin White |
|
|
Lewis Phillips |
|
|
Laura Keen |
|
I agree with the approach of this curriculum. |
Howard Kramer |
|
|
Helen Burge |
|
|
Brent Bakken |
|
Based on conversation from the 07 February meeting, I would be in support of adding more basic development information at the start of the curricula. I will however support the direction of the Editor and working group. |
Sharron Rush |
|
Agree with comments made in today's meeting. Even if not presented as a module, there needs to be an intro section that orients developers to the how and why. Not at all needed to be in depth but it is needed and should be included in the outline. |
Choice | Responders |
---|---|
I reviewed it thoroughly. |
|
I skimmed it. |
|
I need more time, and will be able to review it by the date specified in the comment field. | |
I didn't get to it. |
|
Please have a look at the introduction and learning objectives for Module 1: Semantics and Structure.
Responder | Comments |
---|---|
Shawn Lawton Henry | |
Sylvie Duchateau | In the introductory part, there should be an explanation, or demonstration of why semantics is essential. Showing an example without versus an example with semantics. Who needs semantics, why it is important? |
Eric Eggert | OK |
Kevin White | I am not clear who the audience for the learning material is. If the aim is to teach people how to develop accessible content then I think it misses the mark. While semantics is vital I am not sure it is the first thing I would teach... or more accurately, I wouldn't necessarily present it as the core element of the module. Structure, yes - semantics, yes but I would probably weave it in rather than use a blunt instrument. I think there is something about the basics that would be useful to start with. The "hello, world" of accessibility - this would allow for the explanation of other concepts without scaring people off. |
Lewis Phillips | I think it covers what is needed. |
Laura Keen | |
Howard Kramer | I didn't see anything missing or that should be removed. I wondered if HTML5 and WAI-ARIA should be mentioned after headings, lists, etc., since it is more advanced. |
Helen Burge | Maybe add a high-level definition of what semantics mean. It is the code used behind the visual look of the page. But this might just be me being a bit fussy! |
Brent Bakken | |
Sharron Rush | Not that anything is missing but the approach is a bit wrong. I agree with Howard and Kevin. Helen too noted that structure is a key concept and the module should lead with that. Ease into semantics after doing more explanation and tying the concpets to user experience. |
Please focus on introduction and learning outcomes for Module 2: Menus.
Responder | Comments |
---|---|
Shawn Lawton Henry | |
Sylvie Duchateau | No specific coment on this module. It is clear except that one should recall who benefets from accessible menus. |
Eric Eggert | I struggle with this one in general because I feel that we have not nailed it with the Tutorials. People still use menu roles for non-application navigation. I wonder if we should name and highlight “Navigation” instead of naming the Module “Menus”, which would also be consistent with ARIA role navigation and the <nav> element. Then again I tried to use this logic with the tutorial and the Group didn't like it back in the day. In any case I think this curriculum at this module level should concentrate on navigations and only mention application menus as something to distinguish normal navigations from. An advanced course can then go into detail. |
Kevin White | Menus as the second thing to discuss?! Navigation, yes, menus - don't know? Might be that the module needs to be presented as 'Navigation' rather than 'Menus' because the latter is misleading. Again, it seems to dive in at the deep end in terms of learning outcomes. I would start with common, straight forward navigation patterns (primary navigation, secondary navigation, breadcrumbs, site maps), explain consistency of design, internally and aligned with common usability patterns. Then weave in regions and ARIA for navigation. Then you can move to more complex design patterns and introduce dropdowns, application menus etc. Finally you can cover off how everything done works with assistive technology. |
Lewis Phillips | I think it covers what is needed. |
Laura Keen | |
Howard Kramer | Maybe the distinction between pull down menus and standard menus should be mentioned. |
Helen Burge | Maybe add in the difference between a menu and a select list, as are often confused. |
Brent Bakken | |
Sharron Rush | Prefer "Navigation" to "menus" since it is more comprehensive. |
Please focus on introduction and learning outcomes for Module 3: Images.
Full statement of question.
Responder | Comments |
---|---|
Shawn Lawton Henry | |
Sylvie Duchateau | |
Eric Eggert | OK |
Kevin White | Need to add basic structure of an image element and how assistive technology interacts with images. This also needs to cover SVG images, CSS images, icon fonts. How the code for these are structured is important. |
Lewis Phillips | Looks good. |
Laura Keen | |
Howard Kramer | This looked like a good start. Perhaps some mention of the other benefits of having alternative text - seeing the content when graphics are not downloaded (for example, in an email) |
Helen Burge | Looks good to me. |
Brent Bakken | |
Sharron Rush | Assuming structure will follow outline of the Images tutorial currently posted? The decision tree especially can be useful. Otherwise, agree with previous comments, nothing much to add. |
Please focus on introduction and learning outcomes for Module 4: Tables.
Full statement of question.
Responder | Comments |
---|---|
Shawn Lawton Henry | |
Sylvie Duchateau | Still recall who benefits, who are the users. |
Eric Eggert | OK |
Kevin White | Don't know if the courses would cover this but: structure of a table, how do users interact with tables, simplifying data tables. Courses also don't seem to match up with the learning outcomes. For example, if a learning outcome is around analysing a table with AT in mind, then there would need to be something about how AT users engage with data tables. Not sure if that is what should be presented though. |
Lewis Phillips | I think it covers what is needed. |
Laura Keen | |
Howard Kramer | Looked fine. |
Helen Burge | Personally, more than one header, like using a row header is not supported by a lot of screen readers. But this is a failing of AT not the specifications. Not sure if this is worth adding as a note on possible topics "Assistive Technology Limitations" or might be seen as too changeable? |
Brent Bakken | |
Sharron Rush | The emphasis on AT navigation through a table would seem to require more understanding of AT function. Is the plan then to present different types of AT and how they navigate through tables? Seems a bit muddled. Is there any consideration of LMS and other frameworks that continue to use tables for layout and how to avoid those pitfalls? +1 to simplifying data tables. |
Please focus on introduction and learning outcomes for Module 5: Forms.
Responder | Comments |
---|---|
Shawn Lawton Henry | |
Sylvie Duchateau | Once again, recall who benefits from accessible forms and what are the consequences of inaccessible forms for them. |
Eric Eggert | OK |
Kevin White | Seems to be missing course structures. Also, I know this is high level, but it would be good to start early in avoiding complex language: 'Accessible techniques to communicate validation outcomes' = 'Accessible error messages'? Would be looking at: labelling, instructions (for the form, for specific fields), error messages, reviewing, grouping, multi-page forms, complex elements (vs native elements?), AT and forms, how to test forms |
Lewis Phillips | Looks okay. |
Laura Keen | |
Howard Kramer | Looked fine. |
Helen Burge | The left-hand list has lower case "forms". |
Brent Bakken | |
Sharron Rush | If we mean to continue to make the curriculum user focused, should this (and maybe all) modules begin with a brief "why this matters for accessibility?" Since forms are by far the most common interactive elements, it seems especially important here. |
Please focus on introduction and learning outcomes for Module 6: Widgets.
Full statement of question.
Responder | Comments |
---|---|
Shawn Lawton Henry | |
Sylvie Duchateau | Add who benefits from accessible widgets and what are the consequences for them of inaccessible widgets. Students should also learn how to check their work. |
Eric Eggert | OK |
Kevin White | Could include a refresher in native vs constructed. Wonder if this fits into the Forms section? If not, then relationship is important. |
Lewis Phillips | Should it mention javascript? |
Laura Keen | |
Howard Kramer | Also looks like a good start. |
Helen Burge | Should the use of third party widgets be covered as can be a more common usage? |
Brent Bakken | |
Sharron Rush | Please be sure that we are offer a clear and strong cautionary message about the overuse of WAI-ARIA roles, states, and properties. |
Please focus on Overall Module Structure
.Responder | Comments |
---|---|
Shawn Lawton Henry | |
Sylvie Duchateau | It sounds fine. |
Eric Eggert | Looks good to me. |
Kevin White | Overall this seems like a lift and shift of the tutorials. They would certainly be a core part of the content of any course I created on developing accessible content. However, I wouldn't use their structure as they don't really hang together well as a course. Sorry, repeating myself I think; it isn't clear who the target for training is: existing developers, new developers, testers? There seems to be a mix of outcomes that would relate to a range of folks. I wonder if there is something missing about using frameworks and templating languages. I know we don't like to talk about then but they exist and in many cases front-end devs are not hand-crafting HTML/CSS/ECMAScript but just using a framework and coding the front end in JS. Also hate to say it but "single page apps"? |
Lewis Phillips | Looks okay. |
Laura Keen | I agree with the overall structure. I can't see anything that is obviously missing for an introductory course. |
Howard Kramer | Just wondering as sort of indicated above. Why no lessons on headings, lists, paragraphs, etc.? It seems that should be mentioned first since they are the most basic semantic elements. |
Helen Burge | Overall looks great, my suggestions are minor items that might not be needed. |
Brent Bakken | |
Sharron Rush | It seems to follow the structure of the previous Module, is conssitent in presentation style and navigation, so it all seems fine. Thanks! |
The following persons have not answered the questionnaire:
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
w3c/wbs-design
or
by mail to sysreq
.