Meeting minutes
Setting up meeting, choosing scribe
Module 7,: Forms Design
<dmontalvo> https://
Daniel: background on the module - request from EO on Forms. Module built from Interaction and other additions...
First topic about labels and instructions, covering appearance, names and overall instructions in forms...
overall instructions on steps, placement of instructions also covered in the first topic
… also semantic instructions. 2nd topic Error prevention, now consistent across other areas.
… suggestions for corrections and other requirements covered, and qualified in WCAG...
… with allowances for teachers to adapt to different contexts (e.g. examination example)
… covering multiple topics, including notification placement, and how users can review these...
… first thoughts or suggestions on this?
Carlos: I was thinking about error prevention topic: is this the most appropriate name? We're not dealing only with error prevention but also with what happens when error occurs...
would 'error management' be more appropriate?...
Also one teaching idea missing? To keep data entered into the form fields after an error has been detected as form is leaded again...
identifying which field has an error, if you keep data it makes life easier for all users.
Daniel: Yes. Retitling possible. On data, is this a dedicated teaching idea? Idea is worth considering...
Some other places in the curricula, e.g. when discussing page titles, we discuss best practice, so along the lines of 'this is best practice' is this what you mean?
Carlos: Yes
Daniel: we'll look at additional bullet, or similar to acknowledge this.
… best practice to keep data that is entered, to make things easier for resubmission...
use cases exist where this may not be possible, eg. security may be edge case for passwords, but I see the idea.
Daniel: Best practice is best way to present this
Carlos: Best practice is the best way to present this.
Daniel: we'll take these two forwards, there may be more as we turn to specifics.
Notifications Coverage
Daniel: New topic - notifications coverage.
<dmontalvo> https://
Daniel: this is the last in the sequence. Module 7....
Theres value here. More on notifications relate to forms, fields and validation. But there are additional notifications, e.g. custom widgets.
… Are we OK with how this is? Do we need to cross reference with other modules? I plan to include in interaction design module curricula as well. Link to follow
<dmontalvo> https://
Daniel: The introduction defines the scope, first bullet... explain strategies that people with disabilities use to interact with components of web pages and applications, including links, buttons, controls, forms, widgets, and notifications
… 'and notifications' has been just added. To highlight applies to components for example.
… questions: are we ok to cover this extensively in forms design? Does this need to be expanded?
… to other sections?
Brent: in the interaction design module is that the only place where you've mentioned it, or is it covered in another topics?
Daniel: not explicitly. We have keyboard interaction, gestures and motion. In keyboard interaction, we say this favours voice and touch to say...
notifications are not covered.
Brent: a notification would be considered one of those components to be alerted to - would that need to be specifically mentioned
Daniel: If agreed, I need to take this forward.
… so it's clear we're covering notifications in this one as well.
Carlos: for me this is tough. Deciding where to place it.
… Notifications are most often used in scope of form submission, so I'm ok to keep there, also happy to move to interaction design...
module. and wherever we end up placing it we need to review every other topic to find places that need to be cross referenced.
Daniel: yes. We've been discussing what we mean by cues, landmarks, covering different places from different angles. Plan is to keep notifications in form design...
but also making cross-reference in interaction design.
… possibly too lightweight, but should be in 2 places. Does that address what you're saying?
Carlos: Yes
Daniel: we could have something for next week on this one, expanding across references. I'll point you to specific locations - as we're in more stable situation, ready to come back to...
Daniel: recap - makes sense to have notifications in forms, but also interactions. Currently slightly unclear. Need to expand. Particularly on keyboard topic...
how to review notifications, exit notification, dismiss notification etc. something I will work on
… ready for next week.
<dmontalvo> Sarah: Design posting in the cues. I wonder about how clear we make that to teachers on the curricula planning
Daniel: I'm also worried about this too - as there are aspects of the design, as they have to be in first topics e.g. visual and non-visual cues, may confuse that these come up in different locations. May need to return to meta-referencing dimension...
we may need to describe what we're doing, to highlight these dimensions and why they occur where they do - e.g. visual cues....similar issue to this one in Forms...
not possible to solve now.
Daniel: possibly not as clear as it should be.
<dmontalvo> Sarah: Teachers will recognize this is difficult, some sort of acknowledgment would be needed
Daniel: This is about the overall cross referencing aspect?
… to recap.. I will be working on that and be back with something for next week...
Relationship between keyboard input and other input methods
Daniel: Next agenda item
<dmontalvo> https://
Daniel: We've touched on this previously - briefly, in context of interactions we discussed keyboard, mouse, touch and voice, we don't have specific topics on each...
as there are not a specific set of requirements that split what is needed into the different interaction methods...
There's some on keyboards, but not touch etc. Addressed somewhat in 2.1.
… these additions I propose in the first topic bullet says: explain how keyboard support favors other ways of interaction, including touch and voice...
… to communicate to instructors to communicate to students to plan for this common ground. This might not be the wording, we may end up wanting to name specific ATs, thats for discussion. First...
do we agree on the rationale that there's probably not enough from requirements perspective. re we happy with this formula...
on commonground for interactions?
Brent: From my perspective, I think you're probably right. You're asking if there's agreement that there isn't enough content in that keyboard interactions section of module 4?
Daniel: For touch and voice, there's probably not enough. For keyboard yes. Gestures and motion also, but not for voice.
Brent: in the 1st bullet - 'including touch and voice' I'm assuming...are you asking whether there should be additional touch and voice interaction topics? Is that the Question?
Daniel: I don't think this is about topic. Focusing on this first bullet, are we comfortable just staying this (touch and voice)... do we need to be high level or specific?
For designers is that the right approach or should we get more specific?
Brent: I don't know.
Daniel: MAybe we need to bring this to further discussions next week or Friday.
… for more input. What we say currently is enough, designers are not going to get into level of detail, but need to know this is the basis for further work that needs to be done at a developer level...
open to discuss that.
Daniel: to point people to this to check common understanding.
Daniel: I'll bring this back, so I can update, and we can have more perspectives during the week.
Brent: Yes.
Daniel: I'll make background updates, and keep people up to date via email.
Brent: for me, looking at the designer modules, I need to read it one more time ahead of Tuesday, with all modules to refresh my thinking and check it's coherence with itself.
Daniel: This is not fixed yet, there will not be big changes, but type of change Carlos raised...
… what's convenient for you?
Brent: If you can ping me if there's a change - e.g. heads up on change to interaction module, probably good idea to bring to planning, and see if needs to go to bigger group.
Daniel: I will.
Daniel: let's go to last agenda item. More specific and easier to parse!
Clarifying confusing example
<dmontalvo> https://
Daniel: This is Topic: Orientation Cues...
We added the last bullet, an example that was a little confusing...
learning outcomes last bullet...
… we use example with calendar with background colour. We already use colour elsewhere. This is about orientation cues, so we now say...
Now not use of colour - it's an orientation cue...
Is this now clear?
Brent: so text cues - then example is then icons where a form field is required. When you say 'icons to convey'...
so what is that example to you?
are you talking about a text based icon?
Daniel: visual icon. Could be mapped with colour, in Aria there's advocacy for icons with colour, even though within visual methods colour alone is not enough...
reasons I ask is that we may move from this and use an example of visual cue without colour that is still a cue..
e.g. via text formating, italic, visually clear - but needs thought. Does it need some reinforcement.
Brent: so the example is when it's problematic, and the learning outcome is that they're learn ways to use text cues to supplement that - e.g. example of screen reader needing additional cue to emboldened text, example is additional icon...
to me that is a little confusing. Not clear whether second part of sentence is solution, or part of problem.
Daniel: you mean the 'for example' is creating the problem?
Brent: Yes. What was there before?
Daniel: We had 'for example: available dates mapped in a calendar with use of colour'. Didn't want to use colour - wanted to focus on orientation.
highlighting issue of textual cues.
Brent: for me, second part of bullet is not clear, as to whether it's a bad, or good example.
… a lot of people will use red, then asterisk for required field. Not from example what is best way forward.
Daniel: If we said use text and icons to convey when a form field is required - would that work? Use both?
Brent: that would clarify for me
Daniel: Ok. We may also need to come back to that. We're a small group today. I may send an email to refresh.
… anything else?
slewth: this is a better example, agree with Brent for need to clarify
Daniel: AOB
Daniel: we will discuss more in the planning what has been discussed today...
what we're trying to do is avoid the disconnection, where draft goes to group but group doesn't see the 'before' - so keeping group up to date on what we're doing, so they're familiar with what we've been doing.
… for next Friday EO and next week.
<dmontalvo> Date: October 19, 2021