– DRAFT –
WCAG2ICT Task Force Teleconference

<philday> https://github.com/w3c/wcag2ict/wiki/Scribe-list-&-instructions

Announcements

Mitchell Evan, New participant. Native app side, works for TPGi.

<Chuck> Welcome Mitchell!

Maryjom: Announcements. Next, pull requests are working. (Daniel fixed it, thanks Daniel-Montalvo).

maryjom: integrated approved content into the editors draft. For next week, 2 new surveys.

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-Abstract-change-log/

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-intro-sections/

<Chuck> None from me

<GreggVan> https://go.umd.edu/foia

greggvan: Remind people about the Future of Interface (FOIA) conference next week.

Standup for self-assigned work

<maryjom> https://github.com/orgs/w3c/projects/13/views/8

maryjom: How is everyone on what they have self assigned.

Devanshu: label name is ready.

maryjom: shawnt, how are the includes working?

ShawnT: haven't had a chance yet. will look into it. In the long run is it easier to copy/paste items?

Daniel-montalvo will discuss and get back to ShawnT

maryjom: copying new definitions. Including in new success criteria. If you see a definition in your assigned items, check to see if you agree

maryjom: has taken on reflow. (Add 1.4.10 Reflow). Reflow introduces the term CSS Pixels etc. How does that work on small screens? Discussion needed

maryjom: Additional reflow items. Is there special guidance or interpretation we need to provide

ChrisLoiselle has been working on "AddContributors and formereditors to the document". Not a high priority but there is a way to pull in contributors but not sure how that happens.

maryjom: LauraBMiller took up 4.1.3

olivia-hogan-stark will take 2.5.2

shadi will go for 1.4.13 content on hover or focus

Survey: Review of SC 2.5.4 readiness to incorporate into editor’s draft

maryjom: Motion actuation. 9 ppl said incorporate as-is

<maryjom> Draft RESOLUTION: Incorporate SC 2.5.4 into the editor’s draft as-is

<Sam> +1

<Devanshu> +1

+1

<Mike_Pluke_> +1

<maryjom> +1

<FernandaBonnin> +1

<olivia-hogan-stark> +1

<philday> +1

<ShawnT> +1

<BryanTrogdon> +1

RESOLUTION: Incorporate SC 2.5.4 into the editor’s draft as-is

Discussion: Loïc’s proposal for 1.4.12 Text Spacing

<maryjom> w3c/wcag2ict#62 (comment)

<maryjom> with Loic's substitution would read: For non-web documents or software using markup languages that are exposed to user manipulation and that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

GreggVan: Sounds like you are providing controls for any user to be able to do it. Should be "exposed to user agent" or

"AT manipulation"

<maryjom> “In content implemented using markup languages” with “For non-web documents or software that use markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent”.

<Zakim> GreggVan, you wanted to say "maybe "where the markup is programmatically manipulable" to make the sentence easier to red

greggvan: what if we say it's programmatically accessible.

sam: do we need to add non markup language?

<maryjom> This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "In content implemented using markup languages that support" with "For non-web documents or software using markup languages that are exposed to user manipulation and that support"

devanshu: in android and ios, text spacing is not supported.

if the software does not support, should it not apply?

Maryjom: Some markup may not support that attribute

mitch: word question. Manipulation and modification are both used. If they mean the same thing we should pick one .

<Chuck> +1 we are covered already

phil: agrees with fernandabonnin: we are covered already. don't need an additional note

mike_pluke_: "Programmatically modified" is the phrase we've used in the past.

<maryjom> +1

<Chuck> Non-markup is not in scope

devanshu: if auditing an application how do I indicate this?

Maryjom: not in scope.

<Sam> +1 non markup lang not in scope

<FernandaBonnin> +1

maryjom: if we use simpler language in the substitution and then have a definition we use.

<Zakim> GreggVan, you wanted to say ok to cover what Fernanda said - lets use "exposed to user modification" and define THAT as meaning " <maryjom's language> or controls provided by the softwwar"

greggvan: fernandabonnin mentioned adding "controlled by the software" or "provided by the software" and greggvan agrees.

<maryjom> Poll: Use term "can be programmatically modified and define it to make the substitution simpler, and then provide a definition of it.

greggvan: can be programmatically modified or programmatically modifiable.

<GreggVan> +1 to using support

<GreggVan> it is can be programmatically determined

<daniel-montalvo> https://www.w3.org/TR/WCAG2/#dfn-programmatically-determinable

<Zakim> FernandaBonnin, you wanted to say the s.c text uses supports rather than can

<Mitch11> Yes to maryjom 's poll question

fernandabonnin: success criteria uses "supports"

<GreggVan> +1

<maryjom> In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

<maryjom> Original language above:

<maryjom> Loic's: This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "In content implemented using markup languages that support" with "For non-web documents or software using markup languages that are exposed to user manipulation and that support"

<maryjom> For non-web documents or software using markup languages that are exposed to user manipulation and that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property

<maryjom> For non-web documents or software that use markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent that are exposed to user manipulation and that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property

maryjom: amalgamation of the two (simpler sentence and then have a definition).

FernandaBonnin: keep Loic's text adding what user manipulation is.

Mitch11: +1 to the idea of having a definition. Lots of various phrases/words being used.

Mitch11: needs to be implemented in markup language. Not clear that we need to allow the user to modify the markup, just the text properties. Can this be handled in a definition

<maryjom> Poll: Change Note 1 to: Note 1: There are several mechanisms that enable exposing markup languages to user manipulation. One possibility would be to enable direct access to the file containing the markup language. Another possibility would be to have a built-in mechanism enabling the users to modify the properties stored in the markup language.

<FernandaBonnin> -1

<philday> LauraBMiller: should we be consistent and use manipulation or modification

mike_pluke+ modifying the properties available through the markup

fernandabonnin: suggests not having the note that maryjom is polling on.

philday: to Mitch's earlier point, it's difficult to make a decision in light of all of the changes

Mitch: +1 philday

GreggVan: +1 Philday

GreggVan: err on the side of including the note.

GreggVan: would like to see it in context

maryjom: FernandaBonnin, please make modifications for the definition and note 1 (if we were to keep it, which language makes sense).]

maryjom: will create a survey so that we can look at it all together with suggested changes and additional note suggested by loic

<philday> +1 to suggested chagnes