Meeting minutes
<ShawnT> Today's meeting: https://
Chuck: Yesterday we had some issues managing breakout rooms
… I think we have worked those out
… If you leave a meeting and come back you need to be re-assigned
… I will share my screen
… I would like to do a review of what our subgroup did, then will ask for reviews from the other groups
… The subgroup for accessible views met yesterday
… Thank you for those that participated
… We expanded the scope and added those to user needs
… Focus, and some other areas including overlap with timing and interruptions
… We noted when we thought they may be out of scope
… When we went into the tests and the outcomes we put priority on the textual based user needs
… If there are comments from peers, please feel free to chime in
… We came up with lots of user needs
… Any questions, please q in
JK: Is there a link for this?
<Chuck> https://
Chuck: yes
<alastairc> Today's meeting: https://
Chuck: the first user need started as a group of different user needs
… After reviewing, we combined them into a single concept
… (reads from the document regarding color contrast)
… There were lots of user needs related to this
… We still have them captured in here, regarding testing
… Our outcome (reads from the document)
… The other thing we found interesting: we started a conversation about if current technology supported meeting some of the user needs
… We decided this is not the stage for this
… We felt we could explore this later as this evolves
… Thanks to the work on the maturity levels!
… Next user need: regarding enlarging text
… Another one: we discussed that enlarging text was the focus
Patrick: Regarding personalization
… We had a conundrum in our meeting as well
… Is there some type of idea about what the default should be? Should there be a definition of the baseline?
… A minimum standard?
Chuck: One of the user needs we came up with down below was about a minimum font size
… Much as current WCAG has a contrast ratio, we thought that a minimum font size (not already mentioned) should be the baseline
… We did not discuss other defaults
<jon_avila> We did have a user story on font weight minimum
<Patrick_H_Lauke> minimum font size won't be absolute though - depends on font/typeface itself, size (in CSS pixels) of the screen, etc
Chuck: But we came across the same questions as you did
Chuck: our outcome for the small text one (reads from the document)
… We were thinking in terms of enlarging text, but then it came up - but what if you want to make it smaller?
… We made a note that it can be explored later
… Another user need regarding use of a magnifier (reads from document)
… We had discussed using viewport, but we wanted to be tech agnostic
… Our outcome (read from document)
… Next user need: large text (reads from document)
… This was one of the more complicated ones
… If you are enlarging text it is possible that text onscreen already large by default may become difficult to read
… We discussed ways to mitigate this so it doesn't become overly large
… This one is challenging
… (reads from document)
… Very wordy, might need to revisit. Theory: you can have different size headings
… Both should enlarge, but they shouldn't get to the point that they get to the exact size, or can no longer be viewed on a screen
JK: you said a key word that is not there - proportion
Chuck: Yes.
… I will do 1 more
<Patrick_H_Lauke> (i.e. if there is a visual hierarchy/relationship - indicated by size? - there is still some form of visual hierarchy/relationship after text/content resizing - might be proportional size difference retained, or SOME OTHER visual indication)
Chuck: As a person with age related vision loss (reads from document)
… There might be default minimums, maximums - what it should be out of the box
<jon_avila> We were thinking that other means that were not proportional could be used as long as it was x% of the default
Chuck: It can be customized, but we encountered the issues the other group mentioned
… We did not get through all of our user needs
… We have more work to do
… I will also note we took cues from the subgroups of yesterday that wrote the outcomes inline with the tests
… That really helped
… Then you don't have to jump all over the page
… Jeanne led another group yesterday
<mbgower> https://
MG: I will walk us through that one
MG: I will share my screen
… I am sure this is by design - lots of overlap
… Our group was text appearance and semantics
… Research: we began with this
… We divided the research - the low vision task force
… We divided them by year
… We looked at all of the information related to the topic
… User needs: we defined them against the user needs
<ShawnT> Research - Low Vision Accessibility Task Force: https://
MG: Resizing the entire content - we didn't find specific research but feel it is a user need
… There is still work to be reviewed here
… There are lots of user needs identified
… We then mapped them against barriers, and identified tests that can be done
… We listed the barriers in the table
… I am on page 12 at the moment
… Once we did that, we came up with outcomes
… Some are relatively similar to those from the previous group, but with slightly different wording
… The 1st outcome (out of 8)
… Provides ability to customize appearance of text (reads from the document)
… Captures several user needs
… (reads from document)
… We identified an intersectional one: maximizing text and minimizing scrolling
… turning off hyphenation
… This can oppose other user needs
… We didn't have a great way to capture the contradictory ones
… Outcome 2
… Reflow - we have a number that are not captured here
… (reads from the document)
… We have some aspects we missed, and I captured those with a note
… Outcome 3
… User preferences for text appearance
… (reads from document)
… The 4th outcome
… (reads from document)
… Supports the playboack of text in a reading mode
… Highlighting of the text to support tracking, other needs
… Can be like a ticker tape at the top of the screen
… Outcome 5: uses semantics properly
MG: (reads from document)
… Outcome 6: displays all text in the same orientation
… (reads from document)
… Outcome 7: these didn't quite fit into the outcomes we were making
… Some people get information on the page then print it out
… Outcome 8: we didn't quite finish this one
Mitch: I want to acknowledge the great research from the low vision task force
… It leads in consistent places
… When we said "out of scope" we meant for this scratch pad, and the time allowed
MG: Thanks for that
<Zakim> Chuck, you wanted to say that there are a lot of similarities, and we touched upon captioning
MG: We treated all color and contrast as out of scope for this group
Chuck: There are lots of similarity. We had thoughts about how captioning was presented
… and how that might be configurable
… If we thought something was out of scope, we just wrote that in the notes, then deprioritized them
… That is just the approach we took
… Other subgroups may be able to clearly define the boundaries, great
… But if they do have questions, note them
… If you don't want to lose the thought, don't
… We can review them later on
… Any other questions?
… 2 groups from earlier today
Wilco: We started off going over the testing research
… from there we realized that the support seemed to broad
… We decided to focus more specifically on pointer support and the challenges from that
Wilco: From there we ended up in a multi hour conversation around what is a pointer, what can result?
… What about voice control?
… Is that a pointer effect? Or how can it be a pointer effect?
… What if a camera is detecting you?
… We looked at what can be done with a stylus and pointer events.
… We then moved to different tests
… We ended up going through the user needs
… We used the FAST framework - a number of categories
… Some were more self-evident than others
… So we wrote some additional user needs
… Example: user may not need to do the same action many times
… We started looking at writing up a number of tests
… The first couple were very long
… In writing the tests we started seeing patterns
<JohnRochford> Jennie, would you please post again the link to the doc Wilco is referring to?
Wilco: We started looking at things like pressing and holding a control
… but also orientation of a stylus
… How strong is the press onto the touch screen or tablet
… You cannot rely on these things
… Next we ended up with basically 2 outcomes
… 3 outcomes
… It is in the outcomes section in the document
… There is a higher level
… Sites need to support whatever modalities are available
… (reads from the 1st one)
<Patrick_H_Lauke> (once wilco is finished, probably add a few more words)
Wilco: 2D, 3D, whatever environment, activating a single interaction
… A single pointer position in space
… That is the minimum necessary
… Other things you will have to provide an alternative for
… The 2nd outcome
… Users should not be required to perform repetitive things like fast presses
… The last outcome
… Users should be able to choose and operate controls
… Targets are of sufficient size
… (reads from the document)
… Something like for eye tracking software
… High level point and click is a way to control things at a minimum
PL: I want to compliment what Wilco shared
… We had lengthy conversations about what is input, what is a pointer
… We ended up in a better place for it at the end
… We decided we were slightly skeptical of the term "mobile"
… This can mean small screen, but we decided it is too vague
… This is why we talked about pointer
… It would be beneficial to have a similar exercise for keyboard and keyboard like navigation
… spatial interfaces
… The high level need is most likely the same
… As a user I want to be able to select something, activate something
… These have different concepts, and there could be overlaps
<kirkwood> +1 to point of being skeptical about the term mobile’
PL: One of the aspects of WCAG 2 is the assumption: something is designed to use with a mouse, and WCAG patched it to also work with a keyboard
… It would be good to start one step before that - look at all input modalities
… And provide SCs that take these into consideration
… There is the idea that content will be operable by whatever the user has available and can use
… Example: a kiosk or an ATM - a closed environment
… It may be an exception that the author is not required to make it keyboard accessible
… But for content on the web, you can't make an assumption about the input method the user will use
<Zakim> Chuck, you wanted to say we found "patterns" as well during "tests"
Chuck: I think patterns is a good way to describe what we found as well
… This might be a common area used by other groups
<mbgower> I'd argue you can make assumptions for input modalities, based on the APIs available
AC: This is consistent design
… We started off with research
… There is quite a bit we can reference
… Why is consistent design good in general
… It is more difficult to find some research
<Lauriat> Possible to get a link to the Consistent Design Guideline Scratchpad doc?
AC: We were operating under the concept of reducing cognitive load for everyone
… There are quite a few on consistent interfaces improving performance
<Chuck> https://
AC: Or inconsistent ones causing people to not perform as well
<Patrick_H_Lauke> "content should be operable by a user with whichever input modality they have available/are using right now". there will be exceptions (e.g. kiosk content should not be required to be keyboard-operable if the kiosk itself, a closed environment, will only ever provide a touchscreen interface)
<kirkwood> for a minute perspective could put link of consistent design scrathpad in here:
AC: We had things like (reads from the document)
<Lauriat> Much appreciated!
<kirkwood> oops done sorry
AC: (reads user need about effort to learn)
… (reads user need about preferred icons) this is perhaps a future one
… some research is needed on others
… (continues reading other user needs)
… conversation about programmatic and visual
… For example, if you have links and buttons
*speaker name please?
<Patrick_H_Lauke> Ben Tillyer
BT: If you are a JAWS user
* thank you Patrick
BT: needs consistency
mitch11___: whatever your interaction mode, it needs to be consistent across
<Zakim> mbgower, you wanted to say we also identifed the need of "consistent between programmatic and visual" in our Text Appearance and Semantics group
MG: We identified the same basic need: some kind of consistency between the visual and programmatic
… What happens if a certain text color means something
AC: You will see some overlap
… (reads from Outcome 1)
… (this user need: navigation mechanisms are consistent)
… (reads from Outcome 2: interactive controls have similar function and design)
… another angle on it: consistent controls
… distinguishable from non-controls
… There is an "or" pattern here
… (reads from the document)
… lots of things need to be defined in here
… If there is an essential exception, there may need to be information
… We could refine the guidance to be part of an assertion
… We didn't get onto the 2nd part: needing to identify tasks and options on the page
… We also had (reads from document)
… (regards orienting the user)
… this could be step indicators
… On the icon one, users are able to replace control labels
… This might be a user-agent side thing
… But could be an author requirement
… We need some expertise to continue with that one
… For someone who becomes anxious from change (reads from document)
… Allowing things to be reversed
… depending on what the change of context was
… (moves to consistent operations outcomes section of document)
… You can variations of each input, or we could have a way to make it generic
… Someone has been adding a lot to this!
BT: I ended up expanding on one of them
… Previously, one of the other outcomes
… was about helping a user understand how to use it
… I expanded this: it could be partially communicated to assistive technology
… But also this could have design patterns or instructions
<Zakim> mbgower, you wanted to say assessments for consistency should apply not just across a set of pages, but across a page, something we don't capture in 2.x
MG: Thanks a lot for this work
… We have a bit of a hole in WCAG
… I frequently see failures within a single page
… I think this has to apply both across a set of pages, and within a single page
<Patrick__> what if inconsistency is used to convey meaning?
<Patrick__> AC: [reads over breakout sessions about accessibility tomorrow]
<Patrick__> James Craig (JC) gives brief sneak-peek at cross-browser automated accessibility testing in WPT Introp 2023 and Beyond session content
<ben_tillyer> https://