Meeting minutes
Announcements
Update from Mike on EN
Mitch opened an issue in both WCAG2ICT and EN (2.4.4 link purpose). Will it be included in EN?
Gregg: It is late, but we are trying to incorporate everything - if it is editorial (notes) we are trying to include it.
<Mike_Pluke> I have no audio - looking in to the problem
<Mike_Pluke> Ah, now I have sound
Mike_Pluke: EN update: Got through a difficult meeting on stationary ICT - still quite a few issues on SCs. We are dealing with these. On top of most things. Have also made a few minor changes based on GitLab issues - changes to notes that will need to be fed back into WCAG2ICT.
Mike_Pluke will send details to maryjom
We are doing some tweaks so we may do another release to pull in these minor changes - pass by AG WG for review.
2.4.4 Link Purpose Note 1 – Issue 775
New issue from Mitch. 2.4.4 Link Purpose
<maryjom> MATF Issue: w3c/
Also related issue in MATF - see previous link
Mitch asked for a change to the note.
Currently
2.4.4 has this:
Note 1 (Added) (for non-web software)
In non-web software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)
ISSUE:
The first sentence describes a link as text or an image "outside a user interface control," but links are a kind of user interface control. Taken literally, this would mean links cannot exist in software. Or if I ignore the literal contradiction, "outside a user interface control" adds nothing to clarify what a link is.
The second sentence excludes "general user interface controls", but "general" doesn't add clarity either.
Proposed
Keep only the parts that distinguish between links and non-links.
In non-web software, a “link” is any user interface control that behaves like a hypertext link, and is not a button. (An OK button, for example, would not be a link.)
<maryjom> Note 1 (Added) (for non-web software)
<maryjom> In non-web software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)
<maryjom> Draft note from MATF: [note:Examples of links in mobile applications include, but are not limited to: list items, menu items, navigation bar items, tab bar items and text hyperlinks.]
GreggVan: Not sure why list items is there - if the list item is a link, then it is a link, just like any other text item
<Zakim> bailey, you wanted to ask if context is menu?
bailey: wondering if the context makes it clear that it is a menu or navigation list
Discussion from w3c/
And detail from MATF issue: w3c/
GreggVan: Content should be understandable. Then accessibility beyond that - controls should have some sort of programmatically determined 'label' to help people to know what it is. However, it is quite common to use icons on their own. Does this mean the default should be icon + label?
GreggVan: Or we could have on focus it pops up a label. This could tell you the purpose of the icon.
<Zakim> bailey, you wanted to mention that 508 testing baseline for web has the concept of "visually apparent list"
<bailey> Coming back to lists, I'll note that 508 testing baseline for web has the concept of "visually apparent list"
Bailey: On the previous subject of lists - they have a test for the concept of "visually apparent list", and different test for "lists used for navigation".
<Zakim> PhilDay, you wanted to say Mitch's changes in issue 775 is relatively easy - just shorten our note 1
<bailey> For links in lists, 508 baseline uses: https://
PhilDay: Mitch's change in issue 775 is fairly straightforward - just a minor edit of NOTE 1 and makes it shorter.
GreggVan: According to best practice for people who use a screen reader - if you want a link to act like a button, you should make it look like a button (change the appearance to match the use case)..
It should be coded as a link if it is a link, or as a button if it acts like a button.
GreggVan mentioned this to get people to think about the proposed language change to NOTE 1
maryjom: Could get confusing - buttons can do lots of things. They are user interface controls. There are other requirements talking about these controls needing to be labelled in a meaningful manner.
GreggVan: Why is a button not a link if everything else that acts like a link is a link.
GreggVan: Non-web software may not be written in HTML - it may just be code.
<maryjom> Proposed text: In non-web software, a “link” is any user interface control that behaves like a hypertext link, and is not a button. (An OK button, for example, would not be a link.)
<maryjom> Poll: Are you OK with making this change?
<bailey> +1
<PhilDay> +1
<Mike_Pluke> +1
<maryjom> In non-web software, a “link” is any user interface control that behaves like a hypertext link, and is not an action button. (An OK button, for example, would not be a link.)
Proposed change from GreggVan - "action" button
<maryjom> DRAFT RESOLUTION: Update SC 2.4.4 Note 1 as stated above.
<bailey> +1
<GreggVan> +1
<bailey> I am okay with either, but I also prefer previous (without action adjective).
<maryjom> In non-web software, a “link” is any user interface control that behaves like a hypertext link. (An OK button, for example, would not be a link.)
<maryjom> In non-web software, a “link” is any user interface control that behaves like a hypertext link.
<bailey> +1
<maryjom> DRAFT RESOLUTION: Update SC 2.4.4 Note 1 as stated above.
<GreggVan> +2
<PhilDay> +1
<Mike_Pluke> +1
Bailey: MATF issue was marked as completed on July 4th
RESOLUTION: Update SC 2.4.4 Note 1 as stated above.
1.4.4 Resize Text – Issue 722
Correction: title should refer to Issue 772
End of last week - we thought that we would do the minimal change (which was Jon's suggestion)
<maryjom> Where the platform has text resizing support up to 200%, but where not all text resizes to 200% of it's default due to the resized text already being 200% of the default body text size, and provided semantic meaning indicated through differences in text size is maintained, the non-web software should work with the text sizing features to the extent
<maryjom> the platform provides.
GreggVan: Agree with the semantics, but think the grammar needs work
<bailey> +1 that grammar is weird
<Zakim> bailey, you wanted to note that default ... default is awkward
<bailey> note that default ... default is awkward
Discussion regarding wordsmithing to improve readability
If default size of big text is already 200% of small text, then...
Mike_Pluke: This is one of the 2 items where EN added a NOTE to the table of mapping of 1.4.4 to software
<maryjom> We updated the middle sentence in the intro part of 1.4.4 to read: Where the platform has text resizing support up to 200%, but where not all text resizes to 200% of it's default (because some of the text is already 200% of the default body text size), and provided semantic meaning indicated through differences in text size is maintained, the
<maryjom> non-web software should work with the text sizing features to the extent the platform provides.
<Mike_Pluke> New note added in EN 301 549 that comes after the WCAG2ICT notes: Note 4: Good practice is for the default presentation for text to have an x-height that's at least as big as Arial at 16 CSS px for software expected to be viewed at ~400mm.
<maryjom> For 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.
<Zakim> bailey, you wanted to note ambiguous "it"
<maryjom> https://
bailey: Referencing the Google doc. Mary Jo is working from the PR directly - which is later language
<maryjom> For 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
<GreggVan> For 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 x-height of Arial font at 16 CSS px, which at 200% zoom would be 32 CSS px.
<GreggVan> For 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 the x-height of Arial font at 16 CSS px, which at 200% zoom would be 32 CSS px.
<GreggVan> or 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 large as the x-height of Arial font at 16 CSS px, which at 200% zoom would be 32 CSS px.
<bailey> +1
<PhilDay> +1 to the changes.
NOTE 4 change. Last sentence, ... without losing text size semantics, content or functionality
These changes are just for non-web software. Is that correct?
<maryjom> DRAFT RESOLUTION: For 1.4.4, Incorporate PR #776, as updated in today's meeting.
<PhilDay> +1
<Mike_Pluke> +1
<bailey> +1
RESOLUTION: For 1.4.4, Incorporate PR #776, as updated in today's meeting.