Meeting minutes
Announcements
maryjom: announcements, we must be mindful that WCAG to mobile has their document out for review.
maryjom: deadline?
<maryjom> link to WCAG2mobile - https://
maryjom: will send an email with the due date for comments.
maryjom: We may want to coordinate and discuss. We may want to incorporate some of their content into WCAG2ICT so that our documents harmonize.
maryjom: AG working group is working on the charter that will last for two years. WCAG2ICT is listed in their task force work.
<Zakim> bbailey, you wanted to discuss Q back to wcag2mobile
maryjom: look at their minutes if you are interested in that.
maryjom: yes intent to open issues on WCAG2Mobile. add your name and comment in that cell with any issues that are raised and you support.
bbailey: easier to comment on an existing issue.
maryjom: adding items to the spreadsheet to see where there is agreement.
maryjom: usually a 30 day review period for a working draft.
Daniel: it will usually be extended.
maryjom: there is no announced due date for comments but typically 30 or 60 days.
GreggVan: where is the spreadsheet you are referencing for comments?
bbailey: I was hoping we would focus on wcag2mobile github not the spreadsheet.
maryjom: this is just a placeholder.
GreggVan: this will make our comments internal so that we post an issue publicly when we reach agreement for the most part.
maryjom: do your initial read and include your comments.
maryjom: they have only done the first 15 criteria (or so). There are a number of open issues while they discuss what will go in moving forward.
maryjom: staging success criteria as they get them completed.
maryjom: we have one person who would like to join.
maryjom: Jennifer. She is in a subgroup that meets at the same time as this meeting.
bbailey: the subgroups should be ending soon.
GreggVan: they would probably open it back up at the same time.
bbailey: for the next 30 days, I would suggest using their repo more than our spreadsheet.
GreggVan: I thought we agreed to put the information in the spreadsheet to coordinate.
bbailey: if there is significant dialogue or controversy, we should put it in wcag2mobile public response.
GreggVan: make comments on spreadsheet and then move to repo
ChrisLoiselle: if it is easier to create an issue in WCAG2ICT repo and than move it to WCAG2Mobile.
GreggVan: we also have EN 301 549 and we can double check there with the language they are using. So we maybe should be adding that to the same spreadsheet.
GreggVan: through the EN there won't be much in the WCAG, it would be non web software/non web document.
GreggVan: add two columns one for software and one for documents.
Maryjom: do we need to add a column for closed functionality?
GreggVan: I guess if we want to comment about that.
GreggVan: there is not a one to one match up.
Maryjom: doing an analysis already.
<PhilDay> LauraM: Are there other standards that we should be including in our analysis?
Maryjom: any standards that apply wcag
<bbailey> EN301549 and WCAG2mobile are most time sensitive
Maryjom: they wanted to adjust language to make it clearer so we are incorporating.
<bbailey> WCAG2ICT has picked up some things from EN301549 and wcag2mobile
GreggVan: we have several members on both teams.
EN301549 is the standard, WCAG2ICT is trying to provide advice to the standard.
GreggVan: Trying to coordinate across both sides.
GreggVan: there is no requirement for WCAG to change but in the end it is best to align.
Maryjom: we had similar discussions previously as well. Trying to harmonize all of these things.
<bbailey> Gregg: Harmonization means no conflicts, not necessarily identical
maryjom: please look at the mobile document and the EN if you have time and look at the notes in columns in the spreadsheet and quickly add your thoughts.
Survey results: Review proposed updates to 2.4.2 Page Titled
<maryjom> Survey results link: https://
Question 1 - Formatting: Use of headings vs. parenthetic statements
<maryjom> Link to Q1 results: https://
<bbailey> my regrets for not getting to survey, i have read results and concur with votes
<GreggVan> Proposal 1 - PR 626 shows the different guidance for documents vs. software using the headings "Applying SC 2.4.2 Page Titled to Non-Web Documents" and "Applying SC 2.4.2 Page Titled to Non-Web Software". In contrast, Proposal 2 - PR 633 shows the different guidance using parenthetic statements "(for non-web documents)" and "(for non-web software)".
<GreggVan> Note: Proposal 2 is consistent with they way we have notated differing document vs. software guidance in the current WCAG2ICT Note. This can be changed throughout the document provided such a formatting change is preferred by the Task Force.
<GreggVan> Which formatting do you prefer?
<maryjom> Proposal 1: https://
<GreggVan> 1. Formatting: Use of headings vs. parenthetic statements
<maryjom> Proposal 2: https://
Maryjom: first proposal shows word replacements and guidance in different headings.
Maryjom: the way we traditional have been doing it is proposal 2 for comparison. Parenthetic non web documents/non web software instead of additional headings.
maryjom: so far everyone prefers the existing formatting.
<PhilDay> I prefer the formatting using headings, rather than parenthetic
GreggVan: I would bold because I didn't notice the brackets.
<Zakim> bbailey, you wanted to remind why i had problem
bbailey: subheadings was lukewarm at best. Proposal 2 still has the separation between non web software and non web document so the separation is more elegant.
maryjom: the parenthetic?
bbailey: yes, but more than that. There is more separation.
bbailey: you did the same thing I was trying to do without resorting to a subheading.
GreggVan: add space for formatting. And bold
Maryjom: yes, we can do that.
<ChrisLoiselle> +1 to Bruce as that was my interpretation and how I responded to survey , or hoped to per my answers !
<Zakim> PhilDay, you wanted to say that headings were clear, but we could also achieve it with bold text and more whitespace
Philday: I prefer the headings because I thought they were clearer but we can achieve a similar effect with formatting.
maryjom: it will cause the editors less trouble if we use formatting not headers.
bbailey: disagree with saying that bypass blocks is similar to what you've done.
Daniel: we may want to take the extra work if we are going to do this in several places.
<bbailey> from conversation, now i think headings is better !
Maryjom: I'm on the fence.
Maryjom: both ways are pretty clear.
Will poll.
Headings or parenthetic
<maryjom> Poll: Should we use headings to denote separate non-web document vs. software guidance? 1) Headings or 2) parenthetic "(non-web document/software)"
<PhilDay> 1, but also accept 2
<bbailey> (1)
<ChrisLoiselle> 0 - removing bias of being editor , answered 2 in survey
<Daniel> +1 to headings if we are splitting several SCs now
<GreggVan> 2
GreggVan: heading levels are almost visually identical so I can't differentiate.
maryjom: can't modify the spacing around the headings or the headings formatting at all.
GreggVan: if you can get consensus on format one that is fine with me.
bbailey: assuming only having the headings when it is necessary to do so.
maryjom: we will need to go through the rest of the documents to see if there are other locations where this is needed.
maryjom: bypass blocks would be an example.
bbailey: we would not have subheadings when there is no separate guidance.
<PhilDay> bbailey: Don't create subheadings when the same guidance applies to documents and software
maryjom: where we have non web software and non web documents, we may have to split those out.
maryjom: that will come in a PR.
RESOLUTION: Use headings to denote non-web document vs. non-web software guidance where it makes it clearer - including for 2.4.2.
Analysis for SC language changes
<GreggVan> 3. (Question 1 of 3) Non-web software - introductory info (before the SC language)
<GreggVan> There are a few differences between the proposed text for non-web software in the two proposals. We'll cover these in 3 questions. For this first question, compare the language used to indicate this SC shouldn't be applied as written.
<GreggVan> Proposal 1 does not provide a detailed explanation of why this is problematic - keeps it simple.
<GreggVan> This should not be applied directly as written to non-web software. For software, direct application of 2.4.2 Page Titled is problematic. The following criterion is recommended as a substitute:
<GreggVan> Proposal 2 provides a more detailed explanation.
<GreggVan> This does not apply directly to non-web software through simple word substitution because application titles rarely describe the topic or purpose of the software. However, where the platform supports a programmatic title or name for a software window or screen, when a software application utilizes that feature to provide a unique title or name for each window or screen, the user can more easily find it or understand its purpose. This would
<GreggVan> address the user needs identified in the Intent from Understanding Success Criterion 2.4.2
<GreggVan> Which approach do you prefer?
Survey results: Review proposed updates to 2.4.2 Page Titled
(Question 1 of 3) Non-web software - introductory info (before the SC language)
<maryjom> Poll: Which approach do you prefer? 1) Proposal 1 as-is, 2) Proposal 2 as-is), 3) Proposal 1 with changes, or 4) Proposal 2 with changes?
1
<PhilDay> 2, but would also accept 1
<bbailey> 1 but would accept others
<GreggVan> 2
<Daniel> Happy with two except "does not" should be "should not"