Meeting minutes
Announcements
Mike_Pluke: Not much to update really, it's in a frozen state at the moment, only editorial changes
… List from ETSI and others from GitLab
… The process for considering other changes is complex
… By the end of today people are voting no accepting it as-is
… IF there are further changes there will be another vote
GreggVan: Is any of today's topics more important for you Mike
Mike_Pluke: Page titled is the most controvertial
<Phil_Day> Daniel: Where is the GitLab issue with discussions around page titled?
<Phil_Day> Gregg to add to minutes
GreggVan: I can find the issue and add to minutes
2.3.1 Three Flashes or Below Threshold - PR 794
<Phil_Day> • Link to issue 784: w3c/
<Phil_Day> • Link to PR 794: w3c/
<GreggVan> 10.2.4.2 in Issue # 685 https://
<Phil_Day> <div class="note wcag2ict software">
<Phil_Day> This requirement applies to flashing of content on a screen and flashing of any other type caused by the ICT.</div>
<Phil_Day> <div class="note wcag2ict software">
<Phil_Day> This requirement applies to those visual elements produced by the ICT itself. Content from an external source that is presented through the ICT, is the responsibility of the source. The requirement does not require the ICT to examine or modify such externally supplied content in any way.</div>
<Phil_Day> Daniel: If we can add more explanatory wording - suggest we mention the use cases as examples
the current wording could cause issues in interpretation.
<Phil_Day> GreggVan: Catching up on the discussion
GreggVan: I mentioned web because I wanted to talk about the rationale what this is here
… Same rationale applies if you put it in an email to somebody
… For players if they play something they don't have control
… If you sold the player but package it with content, then you are because it's part of your product
<Phil_Day> NOTE 1: <div class="note wcag2ict software">
<Phil_Day> This requirement applies to flashing of content on a screen and flashing of any other type caused by the ICT.</div>
Phil_Day: Let's go with note 1 first that doesn't contain the problematic phrase
… And then we'll go with note
<Phil_Day> POLL: Should note 1 be added?
<maryjom> +1
<loicmn> +1
<Mike_Pluke> +1
<Phil_Day> GreggVan: add "both"
Gregg: I'd add the word "both"
<Phil_Day> maryjom: This is the exact language from EN
maryjom: This copy is what is in EN v20
<GreggVan> +1
GreggVan: Adding the word both makes it easier to read
<Phil_Day> NOTE 2: <div class="note wcag2ict software">
<Phil_Day> This requirement applies to those visual elements produced by the ICT itself. Content from an external source that is presented through the ICT, is the responsibility of the source. The requirement does not require the ICT to examine or modify such externally supplied content in any way.</div>
<GreggVan> +1
maryjom: Again, exact language than in V20
<Phil_Day> Daniel: Think we need to define what we need by external source
<Phil_Day> ... Adding in examples would help
Mike_Pluke: All of the EN 301 549 requirmeents apply to the ICT
… This was motivated by the TV
<Phil_Day> Daniel: Agree that it is OK in EN, but might need more explanation in WCAG2ICT - we just add more specifics in WCAG2ICT
GreggVan: Don't understand the question. External to the source is English, meaning is not part of the ICT. That's plain English
<Phil_Day> Daniel: Yes - suggest we give an example of "from an external source"
<Phil_Day> GreggVan: Problem with adding examples is that they can be taken to be a complete list.
GreggVan: The problem is what we have in the ADA, where if we put exxamples then people may interpret it as those are the only exceptions
… The web being one of those problematic as the ADA existed from before
<Phil_Day> Daniel: How do you confirm what is external and what is not?
<Phil_Day> GreggVan: Still looking for more explanation.
<bbailey> a third-part auditor could not tell internal from external
<Phil_Day> An example of an external source could include 3rd party content that is viewed using ICT (such as video player software on a smart TV). The creators of the ICT itself have no authoring authority or ownership of this content which is wholly controlled/created by the 3rd party.
<Phil_Day> GreggVan: Still worried that this makes it too specific - the explanatory text could then be used in future complaints.
GreggVan: That language would show up in court becaue it would mean that is what external source means according to the WCAG2ICT That's my concern
<bbailey> so drop the clarification of the example?
GreggVan: Putting it down below, instead of putting it in the note, would be fine
<Phil_Day> GreggVan: Suggest we could just put the first part - the example
Example: An example of "content from an external source" might include third-party content that is not incorporated or shipped with the ICT. In such cases, the creators of the ICT have no ownership of the content.
maryjom: I wrote up a potential exxample language
<bbailey> I agree that "The creators of the ICT itself have no authoring authority or ownership of this content which is wholly controlled/created by the 3rd party" needs more due consideration.
GreggVan: That's not quite an example, that sounds like a definition
<Phil_Day> GreggVan: That's more a definition rather than an example.
GreggVan: an example would be televission shows received by the TV or @@@ media players
… This would imply that ownership is the key
… If I contract to have a movie as part of my product and I say I don't own the movie, therefore i don't have to do it
<bbailey> +1 to either example, -1 for rational as to why example is an example (i.e., +1 to gregg points)
<Phil_Day> Daniel: May be better to not have it in the note - just add as an example below
bbailey: I think that if we have to qualify the example, then it's not a good example.
Phil_Day: Do you have a suggestion?
bbailey: I'd drop the second sentence of the example.
GreggVan: If we add examples that'd be fine.
<GreggVan> Examples include TVs playing broadcast programs and media players that are playing content provided by the user.
GreggVan: Examples include TVs playing broadcast programs, and players that are playing content provided by the user
<Phil_Day> Daniel: That would work
<Phil_Day> NOTE 2: <div class="note wcag2ict software">
<Phil_Day> This requirement applies to those visual elements produced by the ICT itself. Content from an external source that is presented through the ICT, is the responsibility of the source. The requirement does not require the ICT to examine or modify such externally supplied content in any way.
<Phil_Day> </div>
<Phil_Day> EXAMPLE:
<Phil_Day> Examples include TVs playing broadcast programs and media players that are playing content provided by the user.
<Phil_Day> POLL: Should note 2 be added as is, with an additional example beneath?
<loicmn> +1
<GreggVan> +1 to note with example
<Mike_Pluke> +1
<maryjom> +1
<bbailey> +1
<Phil_Day> The example should be separate to the note
<Daniel> +1 to note with example
<Phil_Day> DRAFT RESOLUTION: For 2.3.1, incorporate the two new notes in PR 784, with edits noted in the meeting minutes
<Phil_Day> DRAFT RESOLUTION: For 2.3.1, incorporate the two new notes and 1 new example in PR 784, with edits noted in the meeting minutes
<loicmn> +1
<maryjom> +1
<bbailey> +1
<GreggVan> +1
<Daniel> +1
<Mike_Pluke> +1
RESOLUTION: For 2.3.1, incorporate the two new notes and 1 new example in PR 784, with edits noted in the meeting minutes
1.3.4 Orientation - PR 780
<Phil_Day> <div class="note wcag2ict">
<Phil_Day> Content that is only used on hardware with a fixed display orientation or that has no sensor to detect or change the orientation is covered under the essential exception and does not need to provide support for orientation changes.</div>
<Phil_Day> This is the note that is being removed
<Phil_Day> A non-web document that is only used on hardware that supports a single display orientation, or is only displayed on hardware that is physically fixed in one orientation (e.g. a digital building directory) is excluded by the precondition and therefore does not need to provide support for orientation changes.</div>
<Phil_Day> Above is the modified note
See also PR 790
Rich Diff between these two PRs
<Phil_Day> Daniel's alternative:
<Phil_Day> ###### Applying SC 1.3.4 Orientation to Non-Web Documents
<Phil_Day> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4, when the non-web document is displayed on hardware that is designed to be reoriented in typical use.
<Phil_Day> <div class="example wcag2ict documents">
<Phil_Day> A non-web document that is only used on hardware that supports a single display orientation, or is only displayed on hardware that is physically fixed in one orientation (e.g. a digital building directory) would not be displayed on hardware that is designed to be reoriented in typical use and therefore would not need to provide support for
<Phil_Day> orientation changes.</div>
<Phil_Day> Daniel: If we just copy & paste, we don't follow our own style. Coming back to what we had which is consistent with WCAG2ICT
<bbailey> s/I'd drop the second sentence of the example [the sentence giving a rational as to why the example qualifies].
<Phil_Day> Daniel: we don't have precondition in WCAG2ICT
<Phil_Day> Daniel: Make it consistent with WCAG2ICT & don't introduce new terms
maryjom: +1 to what Daniel just said. He suggested then changes to the example that incorporated what we intended
… We wanted to get rid about "has no sensor", but then we adjusted the language further
<Zakim> GreggVan, you wanted to say replace "precondition" with "a limiting conditions (e.g. if x then ....) that ...
maryjom: Where the known application of the document is it'll never be viewed in multiple orientations. And I think it's pretty well explained in this edited one
GreggVan: Precondition comes out of nowhere in this document.
… We could put the wording from EN at the end
… In WCAG we have "for this"... Eliminating condition at the front of the provision
<bbailey> s/I'd drop the second sentence of the example. If it's a good example, it would not need the qualification./I'd drop the second sentence of the example, the rational as to why the example IS an example./
<Zakim> GreggVan, you wanted to say replace "precondition" with "a limiting conditions (e.g. if x then ....) that ... so it reads "if a limiting
<bbailey> +1 for avoiding the word "precondition" in wcag2ict
<Phil_Day> Daniel: we usually have applies as written, or problematic to apply.
<Phil_Day> I would be comfortable having something like "this applies as written when..."
GreggVan: I'd suggest we move to the last one
<Phil_Day> GreggVan: Would like to propose new text
<Phil_Day> Proposal 1: original 780:
<Phil_Day> A non-web document that is only used on hardware that supports a single display orientation, or is only displayed on hardware that is physically fixed in one orientation (e.g. a digital building directory) is excluded by the precondition and therefore does not need to provide support for orientation changes.</div>
<Phil_Day> Proposal 2: Daniel's modification with Mary Jo's modifications
<Phil_Day> ###### Applying SC 1.3.4 Orientation to Non-Web Software
<Phil_Day> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4, when the non-web software is displayed on hardware that is designed to be reoriented in typical use.
<Phil_Day> <div class="note wcag2ict software">
<Phil_Day> Non-web software that is only used on hardware that supports a single display orientation, or when the software is an application that is displayed only on hardware that is physically fixed in one orientation (e.g. a digital building directory) would not be displayed on hardware that is designed to be reoriented in typical use and therefore would
<Phil_Day> not need to provide support for orientation changes.</div>
<Phil_Day> POLL: Which proposal do you prefer? 1) The current PR 780, as-is, 2) PR 780 with Daniel’s proposed changes, or 3) something else.
<GreggVan> 3
2
<GreggVan> 3 because option 2 is missing critical words
Is this 780 or 799?
GreggVan: EN is saying A but also B. In 79 writing B is thrown away
<bbailey> 2
<Phil_Day> POLL: Which proposal do you prefer? 1) The current PR 780, as-is, 2) PR 799 with Daniel & Mary Jo's changes, or 3) something else
<Phil_Day> From 799 (Daniels) - documents
<Phil_Day> ###### Applying SC 1.3.4 Orientation to Non-Web Documents
<Phil_Day> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4, when the non-web document is displayed on hardware that is designed to be reoriented in typical use.
<Phil_Day> <div class="example wcag2ict documents">
<Phil_Day> A non-web document that is only used on hardware that supports a single display orientation, or is only displayed on hardware that is physically fixed in one orientation (e.g. a digital building directory) would not be displayed on hardware that is designed to be reoriented in typical use and therefore would not need to provide support for
<Phil_Day> orientation changes.</div>
<Phil_Day> GreggVan: Need to do word substitution - instead of applying as written when something else is true
<bbailey> s|s/I'd drop the second sentence of the example. If it's a good example, it would not need the qualification./I'd drop the second sentence of the example, the rational as to why the example IS an example./||
<Phil_Day> GreggVan: working on an alternative wording to add word substitution
<bbailey> my apologies, as I have tried to make minor correction the minutes in one spot, I have only progressively junked them up. I will stop now.
<bbailey> +1 to moving on
<Phil_Day> Phil_Day: Will need to do this offline
2.4.2 Page Titled - PR 793
<Phil_Day> • Link to issue 627: w3c/
<Phil_Day> • PR 793: w3c/
<Phil_Day> Proposal 1: Daniel’s original (9 Oct)
<Phil_Day> https://
<Phil_Day> ###### Applying SC 2.4.2 Page Titled to Non-Web Documents
<Phil_Day> This success criterion is problematic to apply directly to non-web documents through simple word substitution because not all document formats provide support for a title attribute, and document titles don't always describe the topic or purpose of the document. File names, as the WCAG 2.2 Understanding document allows, also rarely describe the
<Phil_Day> topic or purpose of the document – especially where the document names are not under the author’s control. However, where the document authoring tool or technology provides the capability to supply a semantic title style or name for a document, when the non-web document utilizes that feature to provide a unique title or name inside of each
<Phil_Day> document, and/or when a meaningful file name can be supplied, the user can more easily find it or understand its purpose. This would address the user needs identified in the WCAG 2.2 Intent from Understanding Success Criterion 2.4.2.
<Phil_Day> Proposal 2: Daniel’s modification (3 days ago)
<Phil_Day> https://
<Phil_Day> ###### Applying SC 2.4.2 Page Titled to Non-Web Documents
<Phil_Day> This success criterion is problematic to apply directly to non-web documents through simple word substitution because not all document formats provide support for a semantic title style, and document titles don't always describe the topic or purpose of the document. File names, as the WCAG 2.2 Understanding document allows, also rarely describe the
<Phil_Day> topic or purpose of the document – especially where the document names are not under the author’s control. However, where the document authoring tool or technology provides the capability to supply a semantic title style or name for a document, when the non-web document utilizes that feature to provide a unique title or name inside of each
<Phil_Day> document, and/or when a meaningful file name can be supplied, the user can more easily find it or understand its purpose. This would address the user needs identified in the WCAG 2.2 Intent from Understanding Success Criterion 2.4.2. The following criterion is recommended as a substitute for the WCAG language:
<Phil_Day> **2.4.2 Non-web Document Titled:** In non-web documents created using an authoring tool that supports semantic title styles for documents, titles are provided that describe the topic or purpose of the non-web document.
<Phil_Day> Proposal 3: Gregg/Mike/Mary Jo
<Phil_Day> https://
<Phil_Day> ##### page-titled
<Phil_Day> ###### Applying SC 2.4.2 Page Titled to Non-Web Documents
<Phil_Day> This success criterion is problematic to apply directly to non-web documents through simple word substitution because not all document formats provide support for a semantic title style, and document titles don't always describe the topic or purpose of the document. File names, as the WCAG 2.2 Understanding document allows, also rarely describe the
<Phil_Day> topic or purpose of the document – especially where the document names are not under the author’s control. However, where the document authoring tool or technology provides the capability to supply a semantic title style or name for a document, such as page-oriented publishing tools and word processing applications, when the non-web document
<Phil_Day> utilizes the title attribute to provide a unique title or name inside of each document, and/or when a meaningful file name can be supplied, the user can more easily find it or understand its purpose. This would address the user needs identified in the WCAG 2.2 Intent from Understanding Success Criterion 2.4.2. The following criterion is recommended
<Phil_Day> as a substitute for the WCAG language:
<Phil_Day> **2.4.2 Non-web Document Titled:** Where a non-web document is page-oriented and is implemented in a format that provides a "Title" metadata attribute which is editable using the primary authoring tools for that document format, the non-web document has a title that describes the topic or purpose.
<Phil_Day> <div class="note wcag2ict documents">
Phil_Day: my notes in google doc which i cannot screen share, so copy paste to IRC.
Phil_Day we have three proposals in pull request with some discussion resulting in proposal three
<Phil_Day> POLL: Does anyone have any objections to proposal 3. Please vote -1 for an objection
Gregg: So we can work from Proposal 3.
<Phil_Day> Daniel: "page oriented publishing tools" - what does that have to do with page titled?
Phil_Day: Yes [screen sharing]
<Phil_Day> GreggVan: something that has pages (unlike movies)
<bbailey> +1 for proposal 3 except that, consistent with Gregg's comment, "PRIMARY authoring tool" is too narrow.
<Phil_Day> Mike_Pluke: Page oriented - often has a title that can be used by screen readers - just eliminates graphics files, movie files (which also have title attributes)
<Phil_Day> https://
<Phil_Day> https://
Daniel: Where is this phrasing formulation from?
Phil_Day: [pasted link in irc]
<Phil_Day> Daniel: When using screen reader - when browsing movies - you do hear the title - the name
<Phil_Day> GreggVan: Name may tell you the title - but not necessarily the purpose of the movie
<Phil_Day> bbailey: Don't want to revisit the conversation on authoring names -
bbailey: Name an author give to something qualify is meeting 2.4.2
Mike_Pluke: If the movie has a title attribute associated then it coudl describe it
<Phil_Day> Mike_Pluke: May be talking about 2 different things - if movie has a title attribute - it may be different to the filename
Mike_Pluke: If the screen readers can read out, should we then limit this to page-oriented?
GreggVan: If we require that the title describe topic or purpose we cannot say name is the title
<Phil_Day> Daniel - cannot find proposal 3
<Phil_Day> maryjom: The text is in the PR for proposal 3.
<Phil_Day> ... It should have been a separate branch, but the text in the PR now includes.
<Phil_Day> maryjom will create Google doc
<Phil_Day> bbailey: Understand your point, but disagree - we've had this conversation many times
<bbailey> Gregg, I think I may have said I think everybody that disagrees with you understands your point about it being contradictory