Meeting minutes
cribe+
EN clause 10.1.2.3
GreggVan: It goes to JTB. They can either approve or send it back
… When it comes back there can be minor editorials
… I don't know if there is going to be a JTB meeting
GreggVan: If there is a meeting issues would have to be resolved at the end of that meeting
… If JTB approves then it goes to vote, otherwise it comes back to us
<Zakim> Daniel, you wanted to say I thought there was going to be one some time in October
maryjom: NOTE 3: This clause corresponds to a WCAG success criterion at level A. Another clause (10.1.2.5) addresses the same user need, but is based on a WCAG success criterion at the higher AA level of accessibility. ICT that satisifies the higher level of accessibility required by clause 10.1.2.5 automatically meets this clause. Because of
this, there is no need to test this clause if the ICT under test has passed a test for clause 10.1.2.5. But if it has failed 10.1.2.5, testing and meeting this clause is still meaningful, as it is better to pass this clause at level A, than to fail both. NOTE: See Note 2 in clause 9.1.2.3 regarding audio description being in main or
secondary audio track.
… One was replaced by adding note 4, which was correct, but the second one wasn't removed
<maryjom> Remove the last sentence of Note 3 in 10.1.2.3
maryjom: I had said that notes 1 and 2 became superfluous
maryjom: Also there is differences between "described videos" and "described narration"
bbailey: Both terms are used
…
<Daniel> s/described narration/descriptive narration/
<bbailey> VD lost popularity
Daniel: Took it from our Media guide
<bbailey> https://
<bbailey> NOTE 4
<bbailey> Also called "video description" and "descriptive narration."
GreggVan: We should just put all three then
maryjom: We'll have to check clause 9.1.2.3 9.1.2.5 10.1.2.5 and all the 11s
<bbailey> FWIW, 508 defined terms has the same sentence: https://
GreggVan: I have a new filter tool. You can click in the precondition and it filters out the requireemeents
<bbailey> Audio description is also called “video description” and “descriptive narration“.
maryjom: Notes 1 and 2 can be removed from *.1.2.3
maryjom: We should renumber the notes then, remove the extraneous "See note 2", and then add "descriptive narration" to that
GreggVan: In 11, removee notes 1 and 2, fix note 4. And then 11.1.2.5 remove 1 and 2, and fix note 3, and then remove the notes appropriately
maryjom: 11.1.2.5 there's only one note left
maryjom: It's all editorials
GreggVan: Agree
maryjom: I will update my pull request
"controls" to "elements"
maryjom: I just saw that change, one in 1.4.13
… Making sure this is consistent throughout
GreggVan: We have two places where we use content and controls, that's oK to use controls. In other places we should use user interface controls.
GreggVan: The reason it was change to "elements" is because of the navigation factor
GreggVan: There are two different words for two different concepts
<bbailey> elsewhere, we also have had conversation about "interactive elements" and "non-interactive elements"
maryjom: The two places are 2.4.4 and 1.4.13
… We'll hae to check these in here
Are recommended x-height sizes needed in WCAG2ICT?
maryjom: This is for 1.4.4 Resize Text
… This is not an interpretation, this is additional information, may not be needed in WCAG2ICT
… Should we really add it?
GreggVan: I'd leave it off
maryjom: I'll delete this pull request
Draft Resolution: WCAG2ICT not to add recommended x-height sizes
bbailey: I also agree to leave it off
GreggVan: The only group now that would be looking at this would be 508, but they'll be looking at the EN
bbailey: The bit about x-height is not well circulated. I don't think it's common knowledge.
<bbailey> i concur with not adding it to WCAG2ICT
GreggVan: We should say that this is because it favors readability
RESOLUTION: WCAG2ICT not to add recommended x-height sizes
1.3.4 Orientation
maryjom: I just want to make sure that the note and the precondition will be correctly reflected in our PR
<maryjom> 10.1.3.4 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.
<maryjom> above is the example.
<GreggVan> Where ICT is, or includes, a non-web document, and the non-web document is displayed on hardware that is designed to be reoriented in typical use,
<GreggVan> the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.3.4 Orientation except when the non-web document will only ever be viewed on a single locked-orientation display.
<GreggVan> EXAMPLE: 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.
<bbailey> Preview: https://
<bbailey> Preview diff: https://
maryjom: In this case it does have the "except when the non-web document will only ever be viewed on a single locked-orientation display".
GreggVan: You are right that this is redundant
maryjom: I think that will handle that one
maryjom: Let's look at 11.1.3.4
maryjom: For this I do need to update the PR for the examples
<GreggVan> Where ICT is, or includes, non-web software that provides a user interface, and the non-web software is displayed on hardware that is designed to be reoriented in typical use,
<GreggVan> the non-web software shall satisfy the WCAG 2.2 Success Criterion 1.3.4 Orientation.
<GreggVan> NOTE: Non-web software that is only used on hardware that supports a single display orientation, or where it is an application that is run only 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.
<GreggVan> EXAMPLES: of software that is excluded by the precondition:
<GreggVan> * The software on a typical handheld calculator (one that typically would only be used in one orientation)
<GreggVan> * Software that runs on wristwatches (where the software typically only runs in one orientation)(sleep mode being non-typical)
<GreggVan> * Building directory software written to ONLY be used on tablet devices bolted to the wall, all in the same orientation
[[WIP on the PR]]
bbailey: Isn't "run on hardware " too colloquial?
maryjom: I'll change it
bbailey: Running is how a programmer would say it, but maybe not common use
maryjom: The sentence introducing the examples
… is incomplete
maryjom: I will update all of this
Daniel: there is a missing space between closing and opening parenthesis, just before "sleep mode"
bbailey: And there's also "run" which is used twice in the same sentence
GreggVan: I wouldn't even change that, but I'll change "run" to "used"
GreggVan: I like "designed"
maryjom: "used on ristwatches" is better
GreggVan: "content is displayed" works better
maryjom: I am going to put these in the PR. Should you send it to Mike?
GreggVan: We'd appreciate it if you could send these to him
maryjom: OK, I'll send these to Mike
Page titled
GreggVan: I think this doesn't apply to documents or software
… That wasn't the intent of the SC. There are not browser windows once you get outside of the browser
maryjom: I think we have "it's problematic to apply"
<bbailey> https://
GreggVan: Old note seems to imply that as long as it has the name, it passes
maryjom: In CMSs they may have no control what they are named
maryjom: In the EN is not voided for documents
<bbailey> a digital letter has metadata -- so title can be there
maryjom: It is for non-web softwware
… 10.2.4.2
<bbailey> Non-web document titled
<Zakim> Daniel, you wanted to mention also double check the EN definition of audio description and to
<bbailey> Documentation shall list and explain how to use the accessibility and compatibility features required by Chapters 4 and 5. Documentation shall include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.
<bbailey> https://
<maryjom> https://