<shawn> scribe: Laura
<shawn> scribenick: lkee
Shawn: Unfortunately Hidde is not able to make the meeting today. Because of the timeline, I still want to show you some material so you have the background for when Hidde is able participate in discussion. We will not make any decisions today without Hidde. While I prepare, here is background reading.
<shawn> https://github.com/w3c/wai-wcag-supporting-documents-redesign/wiki/Requirements-Analysis
<shawn> breifly skim https://github.com/w3c/wai-wcag-supporting-documents-redesign/wiki/Current-user-flows
<shawn> OLD info on dscisions -- yet some good info on user experience https://github.com/w3c/wai-wcag-supporting-documents-redesign/wiki/UI-considerations
<shawn> read this: https://github.com/w3c/wai-wcag-supporting-documents-redesign/wiki/Prototype
<shawn> https://www.w3.org/WAI/WCAG22/Understanding/non-text-content
Shawn: brief background -
understanding & techniques where "TR" documents. we pulled them
out a while ago
... redesign was intended then. now we're getting to it.
... Important, so I'll repeat: We will not make any decisions. We are missing Hidde's
perspective. Just want people to understand background, ideas,
and options
... so when Hidde is ready for us to see prototypes, we'll be
ready with the background, etc.
... background: when WCAG 2.0 was ready ... there was a lot of
discomfort that we were not able to cover cognitive
disabilities enough
... worked out that WAI - provide supplemental guidance in addition to WCAG
... COGA group wrote big formal document, EO was surprised. should be more
digestible
... redesign includes COGA supplemental guidance
... Test Rules - developing test rules for WCAG. can be used by evaluation tools for WCAG
... redesign project is really cool! - trying to get it
published in 3 weeks
... wanted to get this going even though we're not ready for a
survey. Hidde's time is up at the end of Oct. He's not renewing
so we want to get it finished before his time is up.
... that's it for background. don't like pushing timeline - however, if project doesn't get done in 3
weeks, it might not get done at all.
... 3 options for comments:
... 1. must get done before publication
... 2. nice to get done
... 3. can wait until later.
Carlos: requirements analysis - 1 objective easy to understand. Is rewriting a part of scope?
<shawn> https://www.w3.org/WAI/WCAG22/Understanding/non-text-content
Shawn: it was a dream to re-write
the content - we tried editing the understanding pages but not part of
this scope.
... Hidde would have love to improve the content but not
possible right now.
<shawn> general idea (details not done) https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype-understanding-quote.html
Shawn: incomplete prototype -
some things not yet how we decided - don't nitpick details.
... this has better design, font, layout, looks like tools - mostly
visual design
... about this page information - for screen readers and large zoom - the information moves
to the bottom
... has quotes like we did in What's new 2.1, 2.2
... for understanding - design does not have prev/next at the
top, like current. Prev/next is at the bottom. back to top will be added. we have an open issue - do we need navigation at the top to
allow people to navigation to the next SC. probably can not fit it in 3 weeks - make sure that is
ok?
... questions?
... also looking at - all techniques & understanding -
using expand/collapse. not finalized
... 3 links in navigation 1. All 2. About 3.
All WCAG 2 gudiance we'll look at later.
... COGA example: Supplemental guidance - Steve Lee has worked
on breaking that down
... visual description: name of objective almost 10 words,
previous pattern/ next pattern
... all things look related.
<shawn> not complete prototype of Understanding: https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype-understanding-quote.html
<shawn> example of supplemental guidance https://wai-wcag-supplemental.netlify.app/patterns/o1p05-clear-controls/
Shawn: COGA working on - low vision will also have supplemental guidance.
<shawn> closer (though still some minor bugs): https://deploy-preview-51--wcag-act-rules.netlify.app/standards-guidelines/act/rules/image-button-accessible-name-59796f/
Carlos: comments - I do use a lot of the navigation at the top. I will miss that a lot. what about a smaller one?
Shawn: do you use it for techniques & Understanding?
Carlos: yes
Shawn: good to know.
Daniel: uses it also.
Shawn: do you use it regularly - other than for Rules work? Will other people miss it?
Carlos: I use it in other scenarios.
<brent> For Understanding docs, I use the top navigation about 50% of the time.
Carlos: I use it more now than in the past.
Shawn: And you think other people
use it too? I am not saying we will do this, or not. I'm just trying to
understand different user experiences.
... Carlos you said You used to use the navigation on the
left... what if you could either have the navigation on the left or on
the top?
Carlos: no brainer - navigation on the left.
Kevin: do you mean navigation with all techniques in it?
Shawn: navigation with expand/collapse
Kevin: I can see the value with the use case. I just wonder how expansive that need is. my gut is that's a lot to put in the left nav even with expand/collapse
Shawn: it was there before. we're doing it for COGA for supplemental guidance. These use the same template.
Kevin: 217 techniques - massive amount to put in left nav.
<Donna> Is there a way to make this a faceted search of some kind?
Shawn: go from 1 understanding to the next to the next?
Kevin: having a left nav has value in techniques. I just worry about 217 items in the nav
Donna: if you want to have an index that's great. Anything more than 20 is no longer navigation. Need faceted search. a lot more usable - If you see 200 items you don't see anything.
Kevin: We have that in the QuickRef. This is different use case. I get the challenge that there are too many to process.
Shawn: not making any decisions just gathering information for Hidde. Any more comments?
Carlos: 5 points - 1 about this page box on the right - not a good label - it's about the document, not the page. 2. Lots of that information is relevant and some users will miss it. ... I have to leave to teach a class.
Daniel: prev/next put it above where it is now. About this page - at the bottom is a problem for screenreaders.
Kevin: 1. general criticism of early WAI document design was that there was a wall of text. This design is not doing anything to address that. that's because the main content is on a big wide expanding. column 20 words per line. not enough white space - lef nav would narrow it down.
Shawn: I strongly support flexibility to meet user needs. Some users have large fonts and zoom so as long as it's flexible to meet those needs as well, good to have shorter line lengths for some. Kevin: responsive design
Donna: Do we need to make is sound more inclusive? make sure the description is encompassing.
Jade: Understanding - that's been designed in paragraphs - has the texted been edits - can we add headings?broken down to sub sections - more readable.
Shawn: we want to edit the text. but are not able to do that now.
<shawn> [ Brent fills in history of EOWG trying to help improve Understanding docs ]
Shawn: others agree with Hidde
that it would be nice to update the content itself.
... it's good to have ideas to improve things in the future
even if we can't do it now.
Kevin: in-page navigation
<Donna> Need to drop - thank you all for all the hard work and thought that goes into this!
<kevin> Use exiting WAI Site design pattern for in-page navigation (under Summary box in other resources)
Kevin: code samples - no stand
out style - can we do syntax styling?
... styling for notes as well - it's now gone.
... are we conciously removing for some reason?
Shawn: Kevin to put in github issues. a lot better to have in github than just in the minutes.
<brent> Scribe: Brent
Kevin: I do feel this is a big improvement. It has modernized the content across the board.
Laura: I do agree with Kevin on
the readability with such wide design. There is a balance to
find.
... Also agree to be able to navigate between documents is
helpful. Having it on top and bottom is helpful.
Shawn: *hypothetically* In the Understanding doc , if there was navigation on the left, and previous/next on top, what would you use more?
Laura: For me the previous/next is more helpful than having it all on the left.
Shawn: Seems like there is a lot of support for prev/next nav at the top. The current component is too clunky for the top. Would need to look into the design of those controls so they would look appropriate and fit in.
Daniel: Can we add the link to the repository that should be used for issues on this redesign work so that people can add them in the correct place?
<shawn> GitHub repo to submit comments: https://github.com/w3c/wai-wcag-supporting-documents-redesign/issues
Group noticed that some of these ideas/topics are actually already in GitHub. Please follow up by adding comments and recommendations to open issues.
Link from Agenda: https://github.com/w3c/wai-intro-wcag/wiki/WCAG-2-Overview-info-on-multiple-pages
Shawn: As part of this project we are updating the overview pages, specifically the WCAG 2 Guidance page.
<shawn> draft revision: https://deploy-preview-101--wai-intro-wcag.netlify.app/standards-guidelines/wcag/docs/
<shawn> wcag overview remove some redundancy that when into the Docs page https://deploy-preview-101--wai-intro-wcag.netlify.app/standards-guidelines/wcag/
Shawn: This will include some
changes to the WCAG overview page, not significant, just to
remove some redundancy.
... Looking for ideas on the level of information, presentation
of information and what goes in the two documents.
... We point people to the overview page. When we roll out new techniques and understanding, they will likely get to the All WCAG Documents page more.
... Thoughts, questions?
... In an ideal world, the WCAG Overview page is the best first
place to land when people want to start learning about
WCAG. very high traffic on this page.
... Then we also have the WCAG 2 Guidance page. This
page is also on the main WAI website. It acts as kind of a
bridge to the newly designed supporting documents.
... In Overview page the "What is in WCAG 2" is now more sparse and some of the
content has been moved or reworked and put on the "Guidance Document"
page.
Jade: How much user testing have you done with the Overview page?
Shawn: Some in 2017, mostly not on content.
Jade: Would it be worth doing some research on this before working on these updates?
Shawn: Yes, would be good to do. Need to make some updates now to go with the redesign. UT welcome.
Jade: I have some that may be interested. ... I will get back about this.
Daniel: Added a typo as a suggestion in GitHub. The other thing is, there is a line that says "The success criteria are what determine 'conformance' to WCAG..." This may need to be reworded. Strictly speaking section 5 determines conformance.
Shawn: Please add this comment as an issue so that it can be discusse as needed. Also, the link from the adenda goes to an incomplete Requirements Analysis doc. You are welcom to add your perspectives to the requirements page.
Michele: Please clarify the ask for these two pages.
Shawn: #1 Help clarify/add
information and ideas to the Requirements Analysis for these
documents. (https://github.com/w3c/wai-intro-wcag/wiki/WCAG-2-Overview-info-on-multiple-pages)
... #2 Now that you know how people will get to these two
pages, do you have any more ideas of what content should be on
these pages and how it should be presented. high-level, not looking for wordsmithing.
Michele: What is prompting these updates?
Shawn: With the redesign, the Guidance page will be getting a lot more visibility and should be reworked. Because we are beefing up the content on the Guidance page, we should also look at the Overview page to be sure that content is complimentary but not redundant.
<shawn> scribe: Shawn
survey for Authoring Tools list closes Monday