Meeting minutes
Announcements
EN - all changes have to be in by end of Sept. Goes out to JTB vote, then out for ballot to all members for a yes/no vote.
AG meeting - maryjom mentioned that we want to add minor changes to harmonise with EN - and then issue an updated release to the WCAG2ICT note
TPAC is coming up, and there are some publication blackouts - so schedule may have to be tweaked slightly
GreggVan: How critical is it that we publish updates in WCAG2ICT - as long as the changes go into this version of EN
maryjom: Good point - wondered if EN would reference a dated version.
… Also want to maintain consistency with latest version if possible. maryjom will follow up with Mike Pluke
2.4.4 Link Purpose Note 1 – Issue 775
1.4.13 Content on Hover or Focus - Note 3 (Issue 773)
<maryjom> Link to issue 773: w3c/
<maryjom> Link to PR 778: w3c/
maryjom noticed on reviewing EN 301 549 - one of our notes used the word page, and we didn't do a word replacement
Text from issue: Current WCAG2ICT content for Note 3 in 11.1.4.13 Content on hover or focus states (with emphasis added by me on the words "a page":
Note 3
This criterion applies to content that appears in addition to the triggering component itself. Since hidden components that are made visible on keyboard focus (such as links used to skip to another part of a page) do not present additional content they are not covered by this criterion.
The question is, in other cases we replace "page" with “page” with “non-web document or software”. I'm thinking we should do that here as well - maybe replacing "a page" with "the non-web document or software" so the English makes sense when those get split out into a requirement for non-web documents and a requirement for non-web software.
Another question is whether "links" should be "links or other interactive elements" or "links or other UI controls".
That way the note might read:
Note 3
This criterion applies to content that appears in addition to the triggering component itself. Since hidden components that are made visible on keyboard focus (such as links or other UI controls used to skip to another part of the non-web document or software) do not present additional content they are not covered by this criterion.
<Zakim> bbailey, you wanted to ask if this one we separate, i think not
bbailey: it doesn't read well to substitute (singular) page for (plural) non-web software or documents.
PhilDay: Answer to bbailey's question. 1.4.13 has both non-web documents and software together
[maryjom sharing screen to show PR 778]
Proposal is in PR w3c/
<Zakim> PhilDay, you wanted to say there is a change to line 348 as well in this PR
Clarification - only change is word sub for page.
<maryjom> DRAFT RESOLUTION: For SC 1.3.4 Note 1, merge PR #780 into the editor’s draft as-is
<PhilDay> +1 for proposal
<loicmn> +1
<GreggVan> +1
<bbailey> +1
RESOLUTION: For SC 1.4.13 Note 3, merge PR #778 into the editor’s draft as-is
1.3.4 Orientation - Note 1 (Issue 779)
<bbailey> I will retract my suggestion the GitHub, I am swayed!
Detail from issue: The EN 301 549 has modifed part of Note 1 to remove "or that has no sensor to detect or change the orientation" because it inadvertently provides an "out" for content that is viewed on a displays that can change orientation manually (with user settings).
Additionally, the EN 301 549 only applies this note to non-web software - not to clause 10.1.3.4 for non-web documents.
Existing Note 1:
NOTE 1 (ADDED)
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.
Proposed updated Note 1, and only have this be a note for non-web software:
NOTE 1 (ADDED) (FOR NON-WEB SOFTWARE)
Content that is only used on hardware with a fixed display orientation where a user cannot change the orientation is covered under the essential exception and does not need to provide support for orientation changes.
Proposal in PR: w3c/
Another change prompted by EN. They made a minor change to this note - we are mirroring the change
<Zakim> bbailey, you wanted to say its too wide a loophole
bbailey: Thinks it gives a loophole that should not be there - if it has no sensor, then it cannot do this.
GreggVan: Argued for the change. What does the sensor have to do with it?
… Issue is if it can be changed automatically
GreggVan likes the change - it doesn't reference the presence of a sensor - just whether the orientation cannot be changed.
<loicmn> +1
bbailey: Thinks it could be used as an excuse for having a tablet that only works in a single orientation
<bbailey> i agree that a digital hand-held thermometer (or whatever) should not have to be capable of changing orientation
GreggVan: Thinks that some devices that can be turned may not need to reorient the display - so maybe this requires more than is sensible.
maryjom: Many of these examples are closed - maybe we should have an exemption for closed
bbailey: If you have a product that doesn't change orientation, but you'd like it to - agree that the sensor does not matter.
Text of provision: https://
1.3.4 Orientation.
(Level AA)
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
NOTE
Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.
Applying SC 1.3.4 Orientation to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4.
NOTE 1 (ADDED)
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.
NOTE 2 (ADDED) (FOR NON-WEB SOFTWARE)
See also the Comments on Closed Functionality.
bbailey: Simple handheld calculator - the SC applies, but NOTE 1 is clarifying what constitutes an essential exemption. Why add something about a sensor?
bbailey: misunderstood - thought the change was to add the requirement for a sensor.
bbailey: Now happy with the proposal.
GreggVan: Further discussion about small devices like digital thermometer, smartwatch etc - if it can be rotated
<Zakim> loicmn, you wanted to say that content authors can "block" orientation changes on portable devices
loicmn: Issue is that web developers block the ability to change orientation - so somebody can rotate their device, but the web developer has forced the layout to be fixed and not react to changes to the device orientation (through CSS).
… That is what the original WCAG SC was concerned with
<bbailey> https://
<bbailey> Some websites and applications automatically set and restrict the screen to a particular display orientation and expect that users will respond by rotating their device to match, but this can create problems.
<bbailey> An example is a PDF with mixed page orientation.
<loicmn> For example: https://
<bbailey> Changing orientation sometimes break reflow (which is a separate SC) but this use case is more common than poor support for reflow.
loicmn: Posted link on how orientation change can be blocked
This SC tells you not to do that blocking
loicmn: Showing an example of how it can be blocked - not good practice but it is possible.
LauraM: Can we use the queue - so not interrupting.
GreggVan: The fact that it can be done is why we give guidance on not doing it. It should not be possible for content to dictate that it cannot be viewed in a different orientation.
… Concern - as written - it doesn't limit the application enough - so it applies to everything including calculators, watches, etc.
<maryjom> This SC should only apply where the non-web software is designed for a device where content can be viewed in landscape and portrait.
maryjom shares an early draft
<maryjom> This success criterion should only apply where the non-web software is to be used on a device where content can be viewed in landscape and portrait.
<bbailey> I agree that the regulation concept of "fundamental alteration" falls under WCAG usage of "essential".
<loicmn> Content that is only used on a device that can only be used in a specific orientation is covered under the essential exception ...
bbailey We should use the EN language if we can.
GreggVan: Thinks the EN language should be changed as well.
loicmn
loicmn: Proposed a modified version to avoid use of "should"
<bbailey> If wcag2ict can lead the EN phrasing, GREAT !
<PhilDay> +1 for Loic's modification
<bbailey> I agree we need to avoid "should"
GreggVan: That won't work - my watch can be viewed in the other orientation.
<bbailey> I am okay with LCD strips of characters to be considered as falling under "essential"
GreggVan: If some things are in 1 orientation, and others are in the other orientation, if they cannot change it -then it is a problem
They don't have software that is designed to work in both orientations -
<Zakim> PhilDay, you wanted to ask if we are proposing changing note 1, and then adding note 3
maryjom: Think it is 2 notes, or 1 note & a precondition
GreggVan: Should be added to the this applies - change the content - we don't want EN to add a note. We want the guidance to change where to apply it.
GreggVan: Will draft content
1.4.4 Resize Text - possible minor update to Note
<maryjom> Link to issue 772: w3c/
<maryjom> Last PR 776: w3c/
Added non-web software to what we had last week.
NOTE 4 (ADDED) (FOR NON-WEB SOFTWARE)
For non-web software expected to be viewed at a distance of approximately 15 3/4 inches (400mm), good practice is for the default presentation for text to have an x-height that is at least as big as Arial font at 16 CSS px, which at 200% zoom would be 32 CSS px.
But did notice when reviewed the EN, noticed that non-web document 10.1.4.4 had a similar clause but was different to this, and different to 11.1.4.4.
Proposal is to just say content- and apply to non web documents and software
(Or use the same note in both places)
<bbailey> +1 to keep phrasing consistent both places
<PhilDay> +1 to the change
<loicmn> +1 to have the same text in both places
<PhilDay> +1 to use in both places
<Zakim> bbailey, you wanted to say missing 2nd x-height
bbailey: This isn't quite where we ended up. Should have at least as large as the x-height used by Arial font at 16 CSS px
<bbailey> should be "at least as large x-height of Arial"
GreggVan: x-height varies for different fonts
GreggVan: also confusing to use x-height - requires looking up for each font. Just refer to 16 CSS px
<bbailey> I don't know where use of x-height came from, but it's a better metric for fluid reading than just font size.
<Zakim> GreggVan, you wanted to add "this SC applies to non-web software if it is limited to only 'non-web software that is intended to be run on devices that supports software in more than one orientation"
<LauraM> have a hard stop.
<bbailey> From https://
<bbailey> with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts
GreggVan: add the precondition gets rid of all the other problems that we discussed.
Discussion about x-height - and where it came from. Useful for understanding readability of text, but not consistent with other standards.
… Comment on size of text - x-height is more important for legibility.
GreggVan: Suggests using CSS pixels is more useful
maryjom: Is EN working on it?
GreggVan: yes - actively being debated. x-height of Arial is twice as big as the height of the capital X in Arial.
<bbailey> I like what I see on screen in PR
maryjom: We will wait for EN to propose new language, then we can use this new language for the precondition. Then we may be able to use the existing note. Will send it out for approval this week.
For resize text we will wait for next week.
Page titled: we will have to pickup another time
… it is the last one - we had agreed to incorporate non-web software - EN has - but we need to make sure that there is no application of this to non-web documents
Right now we just have sets of documents, and don't make any other comment. Think it should not be applied.
Still need to work on the above
maryjom will create PR for page titled on non-web software (which was already at consensus) and then we can discuss non-web documents next week.