Meeting minutes
Setting up meeting, choosing scribe https://www.w3.org/WAI/EO/wiki/WAI_Curricula/WAI_Curricula_Task_Force_Meetings#Scribe_Rotation_List daniel-montalvo]
First impressions of contents in module Interaction and Feedback. Anything missing? https://deploy-preview-347--wai-curricula.netlify.app/curricula/designer-modules/interaction-and-feedback/
Daniel: Discussion today is module 7 interaction and feedback to cover interaction design aspects, what interaction should be and also notifications and feedback and a topic on labels and instructions...
… what are your impressions on this module?
In the developer modules we had 6 modules and then complex applications came out...
… this module will try to resemble the same but from a designer perspective. Any comments?
Roberto: In terms of scope it covers a lot of things that a designer should know, I would like to see an example of error management and notification...
Daniel: We could maybe start dealing with the types of errors and how errors are solved but maybe is out of the scope.
David: I have to think deeply on how to cover this issue. I think is important enough to be addressed here.
Roberto: Error identification, suggestion...we have strong ground for that.
Daniel: We should try to expand the scope of errors and related processes. Complex widgets. What else is missing?
Should we define "interactive user interface component"? https://deploy-preview-347--wai-curricula.netlify.app/curricula/designer-modules/interaction-and-feedback/
Daniel: I am not sure how we should name complex interface components, we had a short discussion...
… we said custom widgets or rich application and for that we need to use ARIA. Is interacting interface enough?
… how can we better define them?
David: There is already an available definition. We should have it defined.
Daniel: WCAG says talks about user interface components but not about interaction...
… the interaction aspect is missing.
David: What about actionable buttons?
Daniel: Actionable components sound good also.
Daniel: Any other suggestions?
David: The word interactive might be redundant, and does not apply to user interface components. Not using interaction we avoid confusion.
<sloandr> Usability.gov's definition: https://
Daniel: So interface components are already interactive.
Daniel: I will try to make sure to clarify the distinction.
David: You may have an interface components which is not or can not be interactive...
… having the word interactive in the description of the module it may cause confusion.
Daniel: That is a good point. We should take care of all the different components. I see your point.
David: It might be an easy solution to the problem.
Daniel: We need to adjust the wording and in learning outcomes we have to define the stages of the components if they are visible or not.
… any further comment?
Howard: I would like to hear an example? How instructors skip the interactive issue?
Daniel: If you are focused in the main area of an application and want to move to the menu, how do you define the way to do that? Also elements in the background...
… the designers need to provide some inputs to developers.
Howard: Would you then rename the module and overall focus? Or we are just talking about removing "interactive interface components"?
Daniel: I would remove the "interactive interface components".
Howard: Maybe I am missing something but removing interactive does not seem a solution to me.
Daniel: At his point we should revise the module title to define the types of components that we will define in this module.
Howard: I understood that the change would be broader, I will wait until the new phrasing.
Daniel: Maybe next week I will bring a new suggestion.
… module will stay the same for now and will see possible suggestions.
David: As Howard I will have to give another read.
Daniel: Next week we will discuss it again.
Custom keyboard interactions coverage https://deploy-preview-347--wai-curricula.netlify.app/curricula/designer-modules/interaction-and-feedback/#topic-keyboard-interaction
Daniel: Let's focus on keyboard interactions and how we cover standard vs costumed keyboard interactions...
… is there anything that needs more clarification?
… Is under topic: Keyboard Interaction.
Howard. One question that comes to me is that keyboard interaction is something that designers do and developers implement?
… is that what we are talking about?
Daniel: This is a good point we should describe this process. Designers do have a say regarding use of arrows and other keyboard interactions.
… is something correct or is this something that belongs to developers?
David: costume interactions with no clear design instructions may lead to failures. But no clear in how far is a designer task.
Daniel: Maybe the interaction designers or user interface designers may have a word on that.
Howard: This is not my area of expertise it was more a curiosity.
David: The accessibility engineer is the one that gives directions.
Daniel: The more we include responsibilities the more we cover, designer should also be aware.
David: Even if this info comes from accessibility engineers, the designer is the one that integrates it.
Daniel: we need to be careful not to overload the designers role. They will need to work with the developer to integrate the costumed keyboard interaction.
Sarah: I was wondering to highlight this aspects as teaching ideas for learning teachers can raise that to students.
… if this interaction is a shared responsibility between designers and developers maybe students can brainstorm on that issue.
… something to get the students thinking.
<Howard> Howard: summarizing what I said. Might be helpful to have students discuss the decisions that designers can make, such as the type of pull down menu...
<Howard> that can make a difference for keyboard accessibility. What is the designer's role and what is the developer's role?
<sloandr> Designers should be aware of implications of choosing more complex or non-standard interaction methods, as these need to be communicated to users through the interface, which creates more responsibility for the designer. For example, specifying non-standard keyboard commands may lead to a requirement for the interface to provide a list of these commands in a place that users can find them.
<slewth> Sarah: summarising what I said. Overarching issue is it may be helpful for teachers to help students discuss/generate strategies for decision making, to share their perspectives, and be aware that the strategies they use will need to adapt to different team situations.
<Howard> ... For example, pull down menus for main navigation might be a useful feature for the visual user but if it requires tabbing through ...
Daniel: Collaboration and discussion between roles needs to be better defined.
<Howard> 40 or so menu items would be an obstacle for the keyboard user.
Daniel: if any other person has a comment or should we wrap up?
Next Steps
Daniel: I expect to have a meeting next week. Modules are almost complete I expect to discussed remaining questions appointing to specific modules...
… we are also going to discuss with EO to get their perspective and if they agree with the work that might be beyond WCAG.
… discussion with EO will happen this Friday and you can take part on the meeting.
… thanks for the meeting and let's discuss next week the whole perspective of the designer module