<scribe> Scribe: kevin
<dmontalvo> https://wai-curricula.netlify.app/curricula/designer-modules/forms-design/
Daniel: Going to go through
module on Forms, Notifications and clarifying a confusing
example
... Module 7 on Forms Design was requested as a specific module
as it is a key element of design activity and would be
appreciated
... Some elements from Interaction Design module and some
additional new things included
... Topics in the module include: Labels and Instructions,
Error Prevention, and Notifications
... First open question is about overall thoughts, things that
might be missing or things that should not be there.
Brent: Any topic missing or anything in those topics that should be covered?
<Zakim> kevin, you wanted to ask where form elements are?
<brentb> Kevin: Should this be broadened to form fields, when talking about form elements and the structure of those, (custom widgets, status of elements)?
Daniel: This considers any
component that requires user input and that would be considered
an input field
... if the phrase 'input field' is considered not clear enough
then we can review that use
Mark: I like the consistency, but could be expanded to talk about using the correct fields in the correct way rather than just consistently.
Daniel: There was discussion on standard and non-standard widgets and how these are consistently used and this wasn't clear.
Mark: This just is about using native elements in the correct and consistent way
Daniel: Yes, there could be something about using the standard elements in the right way
<Shawn> [ Shawn notes "line" between accessibility and usability and general best practice etc. and wonders if Mark's point is beyond accessibility? ]
<brentb> Kevin: We are not specifically talking about Elements and Fields specifically. Maybe should be more specific on form design. Worth considering.
Daniel: I will try to take a pass on whether this could be a separate module
Michele: Denisgners may not appreciate what is involved in building custom form fields. Might it be worth informing designers around the differences between native and custom and the relative values and consequences of deviating from standard elements.
Daniel: In previous meetings I did say I wasn't too worried about distinguishing between native and custom as designers won't come with that in mind.
Michele: Unfortunatly, designers tend to have more desire to have styled form elements that would require custom elements. And they have quite a bit of power. This might benefit from additional points on this.
Daniel: We could emphasise the value of using standard elements and highlight the cost and problems that custom fields will bring.
Michele: I think designers aren't
necessarily faimilar on how their designs become code.
... This could explain the interactions that native elements
bring and the challenge of having to code that in.
Laura: Do we need to specifically address things like CAPTCHA?
Daniel: This is included in the Images module. It might be worth including a cross reference to this.
Laura: Agreed
<Michele> [Michele: Just noting that for all of these things discussed - types of form elements, native vs. custom - we can just take the strategy of stating facts. That is, just say "checkboxes are typically used for multiple selections" or "elements need these interaction considerations, which come automatic with native elements" and let students come to their own conclusions.]
Dnaiel: Just to sum up there
seems to be something missing about different field types and
their purpose
... Little bit of a cross reference to CAPTCHA
... And something about differentiating between standard and
non-standard and promoting use of standard
<Zakim> Shawn, you wanted to say accessibility. non-standard design
Shawn: If we think about
including the purpose of fields then we may be going past the
line of accessibility.
... We are constantly thinking about the line between good
design and usability on one side and accessibility on the
other.
... We may be able to drift more into usability in this
case.
... Also, just to summarise what I heard from Michele, it felt
it was more that designers should avoid requesting non-standard
components without good reason
<CarlosD> +1 to support Shawn's concern about crossing the line between usability and accessibility
Daniel: Yes, I think
communicating the impact of these choices on
accessibility
... Regarding usability, we can cover this off lightly rather
than defining these are normative or even 'should'.
Shawn: But what does that have to do with accessibility?
Daniel: Trying to bring it back to using standard or regular HTML elements
Brent: I think we do have to be careful about this line between usability and accessibility. Going back to what Mark was saying it may be worth highlighting how and when fields should be used might be of benefit in a cognitive sense.
CarlosD: I would tend to say that
this was a usability issue as everyone would likely be
confused.
... What I think would be good to address would be the
situation where the designer creates a really fancy widget
which would be difficult to develop and then this would be when
to advise to use standard elements.
Daniel: I am not sure how we might cover this as the designer may still say their style is the priority
CarlosD: I think we should be highlighting what design choices make it difficult to make fields accessible
Daniel: I think the one need to
address is where design choice makes for extra work where
standards compliant does not require this work. Understanding
the balance might be what is necessary to stress.
... I will need to think about how we explore and present this
issue.
Shawn: I think there are some ideas that have been presented but there is a need to consider how it is to be worded.
Daniel: We will bring together a proposal on this and I will bring initially to TF than back to the Working Group.
<dmontalvo> https://wai-curricula.netlify.app/curricula/designer-modules/forms-design/
Daniel: There is a topic called
'Error Prevention'. TF discussed that this may not adequately
reflect what is in the section.
... Some alternative include 'Error Handling', 'Error
Managing', 'Errors'
... The issue is that the section is about more than just
preventing errors but includes positioning and managing.
<jade> Errors seems the most sensible then
Michele: I thought that 'Error Handling' would be good.
Brent: When talking about input assistance you are trying to cover four Success Criteria. The guideline is called 'Input Assistance', could you maybe use 'Error Assistance'.
Daniel: I thought that this might be confusing as we are trying to assist people in avoiding errors. Trying to make it clear that the guidance is about helping people avoid or deal with errors.
Brent: Would 'Error Identification and Prevention' be too long?
<jade> The other topics are just one word, labels, notifications, just errors would match that.
Daniel: We don't have many topics that are that long but could use
CarlosD: Looking at the teaching
ideas we are not really talking about prevention but about what
to do after an error occurs.
... I think calling it 'Errors' would be sufficient but we
could also include something about error prevention.
Daniel: That is a good point although does raise the accessibility/usability issue. So if there is an error did it happen because of a usability issue.
CarlosD: A good point. Accessibility could be related to the coding of labels and instructions
Daniel: We could be a bit clearer
about objectives of labels and instructions.
... I think I will pick 'Errors' for now and we can revisit
when we have the new content.
<dmontalvo> https://wai-curricula.netlify.app/curricula/designer-modules/forms-design/#topic-notifications
Daniel: Notifications applies to form fields but also apply to other interactions with applications, widgets or messages. There are also specifics on keyboard use of notifications.
Daniel: In addition to what we
have in this module, we are proposing to have something in the
Interaction Design module as well.
... Have include a Learning Outcome in the Keyboard section on
keyboard management of notifications.
... Is this something people feel comfortable with or is it
distracting?
Brent: Are there any other areas, other than in the Keyboard section where there have been additions?
Daniel: Only minor additions of '
... and notifications' in places.
... Just in the first and third Learning Outcomes for the
Interaction Design module
Kevin: Makes sense to me
Daniel: If there are no problems we will keep for now and then revisit when we have made changes to the rest of the module.
<dmontalvo> https://wai-curricula.netlify.app/curricula/designer-modules/visual-design/#topic-orientation-cues
Daniel: This is an example in the
Visual Design module in Orientation Cues topic.
... Last bullet says: "use text cues to supplement information
provided through vision only, for example available dates in a
calendar marked with a background color"
... This seems like a failure of Use of Colour so may not be
the best example.
... Proposal is to change the example to something like using
text and icons to convey when a form field is required.
... Does this make more sense or is there need for more?
<brentb> Kevin: I wonder if "required fields" is a good example as it is fairly common. Is there an example that is slightly less common that could be used. example - project status: red, amber, green.
<brentb> ... adding a tick or cross as a second indicator.
Daniel: I picked this because it was a well established techinque. I thought this was a strenght but good point that this may not help it.
Michele: Just for clarity is the lerning outcome to address the sensory component?
Daniel: Mainly that one but also that the designer understand that there needs to provide non-visual cues.
Michele: I don't know why the calendar dates wouldn't work as dates could be disabled, bolded or ARIA could be included for additional information.
Daniel: I may have thought that the common approach was to just use colour but if that is not the case then it might not be an issue
Michele: There are tools that allow for this but I was just confused about the 'text cues' which are visual
<jade> q
Michele: I think it is the 'supplement information provided through vision only' which is confusing.
Daniel: I was trying to stress that visual information that is communicating information is provided in accessible forms.
Michele: I think this is trying to tell students not to rely on just one sensory characteristic but to use multiple ways.
Daniel: This seems to be a broader issue in the wording rather than just the example. I will revisit this all.
<jade> Suggestion: Using text and alternatives as other visual cues together to supplement information, for example using text and icons or colour to convey when a form field is required.
Dainel: That helps, I think I will take another pass at the outcome
Daniel: Thanks for all the input,
I will be looking at the Forms Module and also the example in
Orientation Cues
... Will be bringing this back to the group before we go for
any thorough review.
Brent: Thanks for all the work Daniel and the TF on all this work
Michele: Just to say that this content is being used now and is being really well received
Brent: It is really good to hear when our resources are being used
Shawn: We discussed replacing the term 'Color Blind' as this can lead to confusion about the condition and the impact.
<Shawn> https://github.com/w3c/low-vision-a11y-tf/discussions/121
Shawn: The Low Vision Task Forced
suggested 'Color Vision Deficiency' which is the common medical
terminology.
... Suggestions from EOWG were 'Color Impaired', 'Perceives
Color Differently'.
... I have checked how these look when in context of existing
WAI resources and it may come over as too euphimisly
... Taking off my Team member hat, when this is used in
training it may be delivered much smoother but in other context
may be percieved as a euphimism.
... With my hat back on, the Low Vision TF have recommended
that we do go with 'Color Vision Deficiency'.
<Shawn> https://github.com/w3c/low-vision-a11y-tf/discussions/121
Shawn: Low Vision TF have also suggested that we survey but this may be inconclusive. We do have some evidence of Color Vision Deficiency use.
<Shawn> existing resources: https://github.com/w3c/low-vision-a11y-tf/discussions/121#discussioncomment-1444161
Shawn: There will be an opportunity to discuss after this, this is just an initial update
<jade> CVD is fine.
<brentb> Kevin: Worried about the word deficiency being problematic, negative connotation.
Kris Anne: I feel like 'deficiency' suggests something that needs to be fixed
scribe: 'Impairment' has similar problems
Shawn: I think when you, Kriss
Anne say 'people perceive colour differently' it just sounds
fine within the context.
... Some people with color vision deficieny may just call
themselves 'color blind' in the same way that some people with
a 'vision impairment' would just call themselves 'blind.
... Even if we survey and find 99% of people are fine with
color vision deficiency. In our education we are talking about
the design not disabled people, we are focusing on designing to
enable people and don't really want to talk about people being
deficient.
Jade: Could we have a staged approach, first moving to color vision deficiency, and then revisiting as the debate moves on.
CarlosD: As a non-native english speaker I don't know how common the phrase 'daltonism' is as that is what I would use.
Shawn: Not that common but doesn't mean that we shouldn't consider it
<krisannekinney> \me apologies, I have to drop for another meeting. have a great weekend everyone.
<brentb> Kevin: When looking at the example (user stories), are we using multiple terms in different places based on what we are trying to convey - depending on context.
Shawn: That does make it harder
to provide style guidelines but it might be what we need to
use.
... Unfortunately 'daltonism' only describes one type of color
vision deficiency
CarlosD: In Portuguese there are different words for different types of color vision deficiency
Brent: I think in the US 'daltonsim' would be difficult because it is not in common usage.
Shawn: And 'daltonism' is the 'coke' of color blindness
<jade> colour perception variation
<Shawn> https://github.com/w3c/low-vision-a11y-tf/discussions/121#discussioncomment-1444161
Shawn: I will have a look at how
to include this in the style guide.
... Will look at using 'people who cannot distinguish between
certain colors' in different resources and see how it works
Brent: No survey this week but the usual standing items
This is scribe.perl Revision VERSION of 2020-12-31 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/@@@@/Prevention/ Default Present: Brent, Shawn, Jade, Kevin, Mark, Laura, Daniel, Michele, Carlos, Leticia, MarkPalmer, krisannekinney Present: Brent, Shawn, Jade, Kevin, Mark, Laura, Daniel, Michele, Carlos, Leticia, MarkPalmer, krisannekinney, KrisAnne Regrets: Sharron, Sylvie Found Scribe: kevin Inferring ScribeNick: kevin Found Date: 22 Oct 2021 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]