Review what we would like to present to COGA on May 1st, plan out the discussion
Shawn: I opened up the Lets Users Go Back pattern Jennie worked on
* Jennie received questions by email from Beth who could not attend today. Jennie will reach out to her.
Shawn: I compared what I did with this one. I did provides a search.
… (Shawn reviewed what he had in the document)
… Jennie has a lot more information in hers.
Jennie: John had one as well
Shawn: John was testing if he had access
Shawn: I also did use a simple tense and voice - 4.4.2
… It talks about using simple language.
… (reviewed the document)
Jennie: I think we can break it down further, then some can be automated.
… 1st bullet: can divide ito simple tense, and simple language
John: What is passive tense
… Passive voice is when you make the object of an action the subject of a sentence
Jennie: tools like hemmingway app already test for passive voice: https://
John: Grammerly also tests for this
John: there are some tools that integrate
… example, Microsoft
Shawn: there is readability and other terms
Shawn: the patterns that I did like using double negatives
… there is most likely a check for that too
… It is very similar
John: and they are all integrated into word processing tools
Jennie: some yes, some no. And some places turn them off because of where the data may be stored during use
… Do you feel this is ready for Monday?
Shawn: I think "let the user go back"
Shawn: talks about the different tests needed.
… (reads from the questions to answer section)
Jennie: I would be fine if you present that one.
John: Is this for a multi-step process?
… That's the big issue
Jennie: Some web apps I encounter do not have a back button
Shawn: Lisa talks about not being able to use the back button with some places
Jennie: I think there are multiple use cases. Sometimes you just need a back button and it isn't present or the browser one doesn't work
(group discussed clickable breadcrumbs)
Jennie: I think this is an example of what could be tested objectively, and could easily be testable
John: Yes, this is an example of where information can be lost easily
… where data disappears.
… This could be using the browser tools, or
… the tools within the interactive area.
Jennie: I think a unit test could be run to validate if the browser back button or an internal back button was used, and information was maintained.
Jennie: I think we need to agree on whether or not we can all agree on what is "success" in this case
… then, can we automate or write clear instructions for testing
… After that place, then we can evaluate times where groups may have difficulty implementing
… such as security reasons why not
John: sometimes I have seen a dialog saying that if you use the back button you lose all your information
Shawn: there is the new one - repeated information in WCAG 2.2
… in a step by step process
… example: if you ask the address again
… or need to remember something from a previous page
… But the back button isn't specifically listed
Shawn: it is not as easy as you take a pattern, apply 1 test, and it solves everything
… Looking at the back button, that is one way.
… An undo mechanism is another type
… Telling people not to use the browser back button, when they have added a mechanism
… Would that fail this?
Jennie: I think we need to show this on Monday - that we have come to this place of needing clear definitions
John: I think we have that for the back button
… It needs some sort of help area that says if I correct something on the previous screen
… Which might not be the previous page...
Jennie: And this, again, is where we need to be sure we have isolated aspects like screen or view vs page
Shawn: I think this is an example of our patterns being very broad
… Example: search
… make sure there is a search button, then includes what would be helpful
… It doesn't say "there must be"
… WCAG has yes or no
… for many things
… Is there a back button? That is an easy test
… Or, does the back button work without losing information?
… That's an easy test to write
… But here it also talks about an undo mechanism
… Which may include breadcrumbs
… It doesn't say if you use the back button it does the same thing as moving backwards through the breadcrumbs
… Breaking down patterns into smaller specific patterns or conditions would be good
Jennie: I agree
Shawn: to me, as the patterns, or as making content usable
… it is very broad. We need more details, more definitions
… To really figure out how to make things testable for it
… The plain language one is really good
… You can test for double negatives, you can test for passive voice
… Back buttons one: the user can go back many times
… but does the back button still work the way it expects
… What if they want to use their own?
John: That is exactly right. How do we surface that?
… Maybe that needs to go to the larger group.
… Saying "this is the issue: having the expected result of
… clicking the back button without losing data"
… Should this be a failure?
… We know that happens quite a lot
… We might be bumping up a real technical issue
… The only thing one may do is warn users.
… We could give them the option of going back to clearly let them know
Jennie: I have another option. The warning that you won't be able to go back needs to be provided at the beginning of entering data, in order to provide
… an option so that the user could copy the information they have entered into a different location
John: In order for the user to take an action
Shawn: But that is all information that is not in the pattern.
… What if we say we looked at the patterns, looked at 10 + closely
… We noticed that a lot of information needed for testing is not in the pattern
… This is something the future version of Making Content Usable should include this missing information
… Example: contradictory information, or missing information
… The back button one is a good example.
… It gives people options to do.
… (reads from the More Details)
… These are options
Jennie: that is like the techniques used in WCAG 2x
… ways to satisfy
… There is a difference between the musts: testing requirements
… and the ways you can satisfy with usable options
John: that makes sense to me
Jennie: separate testing from techniques
(group talked about the difficulty with the video example, because it has other elements included)
(group agreed that this could be pulled out into a separate multi-media related pattern around navigation and going back)
(group recommends this)
Jennie: I think Monday is about the lessons learned, and showing key examples
… then giving recommendation for the first sprint or 2
Jennie: do these group members want to participate May through part of June
… depend on requirements for timing
Shawn: for sprint 1 I would like to see more involvement from more people
… Participation, and to see where we go
… The patterns are so broad that it is hard to test against them
… I don't see writing an outline on what to look for and making a guide for testing possible
… I don't think it can be done easily
… To me, how do you test with people with disabilities - there are already methodologies (pretty sure)
John: With your concern about getting more input
… Is it that we should figure out a way to facilitate that too
… From poll, to a Google doc, something very clear so people can give input
… Should it just be a Google doc page that gives clear direction
… And can be broadcast further
… Those were some good examples that we were talking about
Shawn: I think we should be having meetings more often
… The time constraint to doing things asynchronously can be tough
… Having meetings helped us get this in order
John: I fully agree
… Things can get off track when things are done asynchronously
Shawn: I think that for the sprints, to look more into it, it should be once a week
… I would like to get more participation on it
Jennie: I know that meeting weekly is something I cannot do
Shawn: I could, if it happened at the right time
… Yes, I will lead on Monday, and we can talk about the sprint on Monday too