Web Content Accessibility Guidelines Working Group Teleconference -- 16 Feb 2016

<Joshue108> Scribe List: https://www.w3.org/WAI/GL/wiki/Scribe_List

where do we find the WebEx password?

<AWK> We should clarify to people that we will not have a meeting on March 22 (CSUN conference week)

<AWK> Who will be at CSUN this year?

<AWK> Andrew will

I will be there

<Wayne> +1

<Ryladog> +1

<Rakesh> +1

<Mike_Elledge> Not Mike Elledge :^(

<SarahHorton> +1

Kim: I am an employee of Thompson Reuters who recently joined W3C. In the legal division as an attorney
... I've been doing accessibility work for a number of years. Previously UX specialist and tester and prior to that a documentation author

<marcjohlic> +marcjohlic

Kim: transcribe documentation and images for screen reader consumption
... super excited to learn about WCAG and learn from everyone

LVTF Accessibility Requirements for people with Low Vision doc - ready for FPWD approval.

<David> Would like to confirm TPAC today..

<Joshue108> https://www.w3.org/2002/09/wbs/35422/LVTF_COGA_FPWD/results

Josh: Have a look at Low Vision Task Force A11y Reqs. Can this go out as first public working draft?
... Let's look at survey
... Good news is we have a thumb's up all around

AWK: These are stake in the ground of what Low vision end users need. When done, next layer looks at the delta between WCAG 2 and user needs.

<laura> This LVTF document will provide the foundation for planned future work: http://w3c.github.io/low-vision-a11y-tf/requirements.html#h-sotd

AWK: Then we can structure what SC is needed and how to test. This is intended as a foundational document.

David: Did you say this has nothing to do with browser zoom?
... If this turns into a requirement, how can we say?

AWK: User needs related to text size, user needs to change the size of text without affecting the interface
... A lot of what we are talking about will come later

David: If we are going to flush out text zoom this will be very interesting with CSS. Suggest to leverage available language.
... Other ways to meet responsively

AWK: One of the most important things we have in here.

David: Responsive shows a lot of hope in this area.

<Joshue108> ak way

Mike: Comments do not block approval.

Wayne: Question for Michael. Do we have an XML structure for bibliographic info?

Michael: There is a JSON structure

Wayne: Is it granular?

Michael: W3C has its own format, JSON and respec script compiles into its own format

Josh: Any blockers to keep this from going to public review?

RESOLUTION: LVTF approved for FPWD

COGA Task Force draft of Roadmap and Gap Analysis doc - ready for FPWD approval.

Josh: COGA Gap Analysis. We have Lisa on the phone who will take us through comments and questions
... Michael did you want to speak to your comments?

<Lisa_Seeman> https://rawgit.com/w3c/coga/master/gap-analysis/

Michael: Links are meant for temp uris. Will need updating for GitHub. Abstract: I would want abstract included in WG approval

<Joshue108> https://rawgit.com/w3c/coga/master/gap-analysis/

Michael: Heading that is repetitive. Should only be 1 heading with a given name.
... Structure needs review. Sentence fragments is a problem. Need good grammar. Blocking comment. Need editorial pass
... References are needed and structured properly before publish
... For these reasons I believe it is not ready to go.

Lisa: I was hoping the editorial draft would be done before this call.
... One other thing. Confusion with the summary of paper on user safety. This summary got left out. Substantial issue to keep people safe online.
... Do we need to go back and say when Michael gives us a green light we can move forward or do we need to come back for review?
... Is there anything non-editorial?
... Anything more substantiative?

Josh: Yes and Yes on the first part.
... Regarding the 2nd point this would be a great opportunity for anyone to give feedback on the content.
... Feel free to comment and bring to Lisa

Michael: If I were in the WG I would want to see this again before approving. If I were you I would ask for a re-review

Josh: Personally I do not want to be a blocker.
... Let's dot i's and cross t's

<AWK> Are there specific dates that COGA is trying to hit?

Lisa: Yes. There is a general suggestion that we get on an publish quicker. There's a bit of dichotomy. Mainly a summary of other works.
... Need to get ready for TPAC and CSUN
... To get the next version out for TPAC next year. Need to fill in Roadmap

Josh: It's really your call. Do you want to do another iteration with WG?

<AWK> I'd prefer to re-review next week after the edits are done. There are a lot of changes to do.

Josh: Noone is saying there are substantive issues

<jamesn> +1 to AWK

Wayne: I wondered if they were being pushed to go to publish. No objection.

Lisa: Process is simpler is we have a provisional yes if the editorial updates are made

David: There's a lot of pressure to publish. I think it would great to put this out.

James: How long to take the edits?

Josh: Not sure if they can be done next week.

Michael: Will not be done sooner than next week.
... Doesn't hurt to go to approval next week

<David> COGA is 9,400 words

AWK: I prefer to rereview next week

<SarahHorton> I'd prefer to wait for edits

Josh: No net loss. Let's wait til next week. Lisa, are you okay with that?

Lisa: Yes. I'm ok with that. I want folks to know that are reading it over that there are known grammatical and spelling issues.

Michael: I will resend when I'm done with edits.

RESOLUTION: COGA will be left open for editorial updates

Josh: David is right. I would be nice to get a couple things out.

TPAC 2016 details

Josh: Michael, any news on TPAC?

<David> should we book our flights?

Michael: TPAC is in Lisbon in September

<MichaelC> TPAC 2016

<David> Are we definately meeting

Michael: 19-23 September
... We have an opportunity to say if we want to meet there
... Pretty sure we want to meet. Hotel arrangements will be available shortly

Josh: David, yes we are meeting. Michael will we have surveys out?

Michael: Next couple of months or two. By April
... Likely to be May or June
... I plan to be there the whole week but I am waiting to book my flight
... Usually an organized hotel.

David: There is one.

Michael: Sometimes advantageous to use the assigned hotel sometimes not

Josh: Any other questions?

Katie: Sorry on mute. Has the host hotel been named?

Michael: Not on landing page. Will be posted when ready to announce it.

James: Any groups meetings we want to avoid overlapping?

<David> avoid aria and html

Michael: Can list up to 2 groups, e.g. ARIA. But may end up overlapping

<David> ok

Extension framework requirements - discussion/changes to paragraph 2.2.

<David> you have a Leslie on (like the organs of the 60's

<Joshue108> https://www.w3.org/TR/wcag2-ext-req/

Josh: Extensions framework. Suggested change to paragraph in 2.2 in the extensions to WCAG 2. Suggested edit in survey.
... Positively received in survey but concerns raised on the call

<Joshue108> https://github.com/w3c/wcag/pull/162/files

Josh: Edit in GitHub to suggested text

<Joshue108> Existing success criterion may be modified, but the resulting change must still satisfy WCAG 2.0 success criteria.

<Joshue108> Existing success criterion may be modified, but a page that satisfies the changed success criteria must still satisfy the original form of the success criteria as well.

<David> +1

<David> WCAG definitions

James: What do you mean by "page"?

Should that be "web page"?

Josh: We have some WCAG safe words

James: I can see that some criteria require re-rendering page in a completely different form that may not satisfy the original success criteria but it's a user choice.
... Functionality still satisfied in original form

Michael: Does this bring us into alternative form territory

Josh: One of the reasons this needs to be narrowed down to a unit of page because of push back
... Original text was too broad
... Other I think I can live with the current text
... We may get into more trouble specifying a unit like page

<laura> Web Page definition: https://www.w3.org/TR/WCAG20/#new-terms

<Joshue108> 8> Existing success criterion may be modified, but a webpage that satisfies the changed success criteria must still satisfy the original form of the success criteria as wel

Michael: Unit of conformation is a unit of a web page which has a definition. It would be a radical change to adjust that. It would get complicated.
... We need to live with this for WCAG 2. extensions

Josh: I think that to use something like "web page" gives this a point of reference might be a good idea to use it eventhough it might be limited.

Katie: I agree with Michael. We need to be careful about that. If someone can give me something not on the same web page where a page has multiple overlays, is still considered a page.
... How do people view that? Does anyone have another scenario where a page is not a page?

Josh: Changing and repurposing content. Can you live with "web page"? I can.

<laura> “Web Page” It is important to note that, in this standard, the term "Web page" includes much more than static HTML pages. It also includes the increasingly dynamic Web pages that are emerging on the Web, including "pages" that can present entire virtual interactive communities. For example, the term "Web page" includes an immersive, interactive movie-like experience found at a single URI. https://www.w3.org/TR/WCAG20/#new-terms

James: What is our definition of web page

Josh: Not very good.

David: I think it is pretty good

https://www.w3.org/TR/WCAG20/#webpagedef

Lisa: Looking at mobile. Maybe there should be a shift toward the term "page"

Josh: Make it platform agnostic

Lisa: Assuming folks don't read definition

Josh: Using page is forward thinking
... I think we need to look at existing sucess criteria. I like Lisa's idea that it bridges different domains.

<David> it is a single http adress

Josh: Michael do we need to get this agnostic definition into the framework?

<David> a web page can change after loaded but as long as it is at the same http address it is still the same page

James: I still think this can be misread. The function still need to meet original success criteria. Doesn't give user choice
... We are going to require content rendered for some users where it doesn't meet original SC but it is the user choice.

Josh: Right. The user's choice might break WCAG

<Zakim> MichaelC, you wanted to say minimize constraints in extension requirements; they inherit all the WCAG requirements and to say the requirements do say need to be able to fall back

Michael: For the extension requirements documents we should minimize contraints. If we can avoid ruling something out we should.
... Extension requirements inherit WCAG requirements.
... There's extension requirements that it should meet WCAG 2 on its onw. This is interesting challenge. You need to conform to both.
... Not always possible. Puts us into an interesting bind.
... If we identify places where this happens we say this needs to be part of post WCAG 2 guidance and not part of the extensions

<Joshue108> Existing success criterion may be modified, but the resulting change must still satisfy relevant WCAG 2.0 success criteria.

Josh: Looking at this as a function of time. If user makes change to UI and satisfies their requirements, previous state does not matter

<Joshue108> A11y stoicastic modelling..

Sarah: One thing about the current version and the new version is that the actor is not clear.
... First actor is SC. In revision, the actor is the resource and the page needs to satify success criteria.
... One thing we are struggling with is how the relationship between SC and extension exists vs. resources that must satisfy the cumulative requirements.
... Point: We are talking about extensions and their effect on the SC we are trying to satisfy.
... Extension modify existing Success Criteria but together but need to make sure resource meets WCAG 2 criteria plus extension

Josh: How about "web page"?

Sarah: I think that changes the focus on the section we are updating because "web page" is a resource

Josh: Ensure that web pages that conform to extension also conform to WCAG 2.0. We are actually talking about Web pages.

Sarah: I agree it is restrictive. I use WCAG to test desktop and Mobile. There's a lot of use. Web page limites it.

<alastairc> Are we trying to say something like this? Existing success criterion may be modified, but they cannot undermine a web page's conformance to WCAG 2.0 without the extension.

Josh: Further in paragraph we use the term "page"
... "page" may be more inclusive

Do we need a definition of page?

Josh: Give an example of how SC can be modified and show applicability and results of modification.
... Should we use the word "relevant"?

Wayne: I don't know if we have to worry about how the person uses the criteria and modifies the page for themselves. WCAG should provide flexibility.
... I don't understand issue

Josh: Which issue?

Wayne: Why a modification a user does should apply at all?

Josh: It boils done to conformance requirements

Wayne: I understand but think this might be a contradiction

Josh: Look at terminology we are using. This is important. Need to be careful not to confuse people with this stuff.
... Michael was getting into deeper issues. These should be worked into WCAG Next

<laura> Currently “Page” is used elsewhere in the document: in 2.4 and 2.5.

<Wayne> +1

Michael: Chatting with Judy. I believe we should put everything on the table that we need to whether or not we think they will work. But need to be cautious with extensions.
... If we are able to temper expectations then not limit ourselves

James: What was the objections?

Josh: The original SC was diluted by extension

Katie: I think I know where Wayne is coming from. Our requirements should not have to do with what the user is going to do with it other than having flexibility

<SarahHorton> "the resulting change" to what? If we could add that it would help

Katie: If a user stands on their head, turns left 3x, should not be our purfew. Should take into account what technology is capable of
... Going back to LVTF. What do people need who are LV? What does technology allow for that.

Josh: I agree. But drafting and writing this framework we need a point of reference that is objective
... Let's make as clear as possible
... Let's just push it out.

<Wayne> +22

Josh: I think it's clear. I like the original
... In broader sense people can understand what web pages are.
... Does anyone object to this going out?

Katie: Josh is in rare form today : )

<alastairc> no objection from me

<Mike_Elledge> +1

<laura> fine with me.

<marcjohlic> +1 to going out

<laura> +1

<Ryladog> +1

Josh: I'll work with Michael and Andrew on Thursday to get out for public review
... Wrapping up early today

<Mike_Elledge> bye all!

<alastairc> \me can anyone point me to documentation on suggesting changes to the github docs?

RESOLUTION: Leave Extensions framework document open for discussion by editors to discuss going out for public review

trackbot, end meeting

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

16 Feb 2016

Attendees

Contents

LVTF Accessibility Requirements for people with Low Vision doc - ready for FPWD approval.

COGA Task Force draft of Roadmap and Gap Analysis doc - ready for FPWD approval.

TPAC 2016 details

Extension framework requirements - discussion/changes to paragraph 2.2.

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output