Meeting minutes
Module 6, new proposal
<dmontalvo> https://wai-curricula.netlify.app/curricula/developing-accessible-content/custom-widgets/
DM: recap from last week
… comment that Module 6 was too theoretical
… request to add real examples of widgets
… like buttons, carousels, and such
… new proposal has such widgets
… have such examples but now seems quite repetitive
… how can we avoid such repetition?
CD: didn't feel like repetition to me
… maybe when translating to teaching material
… but seemed ok to me
… one suggestion is to address the repetitive topics in the first topic
… but we may be speaking about that topic later on
<Howard_> scribe Howard_
<Howard_> Shadi: Looking at first topic, it sounds abstract and dry. Hard time differentiating between the 4 learning outcomes.
<Howard_> ... Do have examples in teaching ideas. Learning outcomes are a bit more abstract.
<Howard_> ... Custom buttons is exactly the opposite. Learning outcomes are clear but examples are not.
<Howard_> ... Actual concepts are missing.
<Howard_> ... 1st topic - too theoretical. Other topics, more of a course content than curriculum. Too little concepts in them.
<Howard_> ... Is there a middle way to teach these concepts.
<Howard_> ... Latter topics seem repetitive and don't explain the topics well. Why only explaining these 4 and not others.
DR: from a higher-level view, I know what button, list boxes, and carousels are
… but widgets seems abstract to me
… understand the concern on repetition
… wonder if there is some way to keep these recognizable ways
… would want to know that courses teach these types of components
Shadi: Sees Donal's point. Looking at learning outcomes for module -
… first item: create custom widgets. That's the end result. Need to understand
… the DOM, keyboard interaction. These latter would be more the topics.
… Hypothetical: keyboard interaction. Learning outcome would be students would understand
… their use in carousels, tree view.
DR: widgets is a catch-all term
… other modules are more recognizable
… feels somewhat cryptic
DM: understand problem with that term
… is there need for further explanation?
DR: in the new version it is clearer because of the topic titles
… coming to this from a marketing perspective
CD: see different sides of this discussion
… current approach doesn't help developers decide which techniques to select
… for example, use standard button or custom button
… many developers need to decide that
… guidance on when to extend vs use native HTML
… these concepts seemed clearer in the previous version
… focusing on specific widgets does not explain these concepts sufficiently
… also missed examples of inaccessible custom widgets in the Extending Semantics topic
… for example button using DIV vs BUTTON elements
… motivates students to do it in an accessible way
DM: agree that decision on using native vs extending semantics needs to be clearer
HK: don't feel strongly at this point
DM: maybe keep current topics names
… and make underlying concepts more clear
… for example keyboard interaction
https://www.w3.org/TR/wai-aria-practices/
SAZ: which widgets will be listed at the end?
… ARIA Practices lists 27 types of widgets
DM: think these are the most commonly used
… could add tree and tab-panel
Shadi: a bit uncomfortable with listing approach.
… Can see what working group says.
… Between tab panel and carousel, so much similarity.
… A fan of teaching concepts where students can apply these concepts
… elsewhere. Live regions for example. On hand, agrees with Donal's input.
… Are there other ways to make it clear. Paraphrasing Donal: 'custom widget'
… is too vague. How can we make it clearer?
… All agree students should be able to create custom accessible widgets such as
… buttons. Students should be able to code custom widget practices instead of listing all 27.
… Don't think designers make the decision on whether to make a custom button, keyboard.
… These are concepts developers need to master.
… Perhaps swung too far from concepts to concrete examples.
DM: would rolling back to the concepts but adding more relation to the different types of widgets be an acceptable approach?
… add learning outcome at the module level listing the widgets that will be taught
… and focusing the topics more on concepts than on particular widgets
DR: got excited by seeing the content at a glance
… then see ARIA Practices has a lot more
… need to keep that at a glance aspect
Shadi: Do you think there are design categories in the aria design
… spec? Example: keyboard interaction such as tree view and tree grid.
… Would have the keyboard aspect and types of widgets right there.
… But would need to categorize these concepts/techniques.
CD: do they have standard HTML equivalents is one question I use to categorize widgets
https://www.w3.org/TR/wai-aria-1.1/#widget_roles
Shadi: just looked up aria spec itself.
… Different categories shown on the spec.
… How to combine teacher and student view. Our primary audience is the teacher. Does subscribe to the "at a glance" approach.
DM: need to be very clear about the widgets being taught