Meeting minutes
Announcements
We will try and deal with the questions that will be quick to resolve first, then through the rest
Survey is long - so we need more time
<PhilDay> +1 to staying later today, -1 for tomorrow
<olivia> I can stay a half an hour later!
We will extend the meeting today - and if we lose too many people we will have to continue next week.
Survey results: (Group 3) Review changes due to comments on second public draft
<maryjom> Link to survey results: https://
<bruce_bailey> +1 to easy items first
bruce_bailey: When we say software, do we always mean non-web software?
maryjom: Yes - as defined
After Q12 the number of responses drops off
<bruce_bailey> that was my understanding, thank you
Question 8 - Issue 436 part 1 (replacing "user agent"): The definition of 'large scale' needs substitutions or notes
<maryjom> https://
ISSUE: w3c/
Google doc: https://
7 preferred option 2 as is
Both Qs 8 & 9 are about issue 436, both had unanimous results
Proposed changes for Q9: https://
<bruce_bailey> w3c/
Text for Q8, option 2:
Option 2: Provide word replacements for ‘user agent’ and ‘ in Note 3 & 4
NOTE 3: The actual size of the character that a user sees is dependent both on the author-defined size and the user's display or user agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors
would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the [user agent or non-web software] for display. The point size should be obtained from the [user agent or non-web software], or calculated based on font metrics as the [user agent or non-web software] does,
when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.
NOTE 4: When using text without specifying the font size, the smallest font size used on major browsers, [user agents, or platform software] for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, [user agents, or platform software], then it would be
reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.
Q9
Option 2: Mitch proposal
NOTE: When evaluating non-web documents and software, 1 point means 1.333 CSS pixels.
<maryjom> DRAFT RESOLUTION: Incorporate the changes proposed in Option 2 into the definition of 'large scale', as proposed in survey questions 8 and 9.
<PhilDay> +1
<olivia> +1
<FernandaBonnin> +1
<GreggVan> +1
<Bryan_Trogdon> +1
<bruce_bailey> +1
<ChrisLoiselle> +1
RESOLUTION: Incorporate the changes proposed in Option 2 into the definition of 'large scale', as proposed in survey questions 8 and 9.
Question 1, Issue 465 Part 2 (SC 2.1.1 and "keyboard interface"): Seeking clarity for key term 'underlying platform software'
Google doc: https://
<maryjom> Link to survey results: https://
ISSUE: w3c/
This came from a horizontal review issue. We started on this last week with parts of the proposal - this is a continuation.
Had to do with the definition of keyboard interface
5 liked as is, 2 wanted something else
<bruce_bailey> Anchor for question 1 in survey is: https://
first question - talk about platform software. Other elements are covered in another question
bruce_bailey: Confirming which q we are on.
Still on Q1 of survey
Firstly, do we agree with removing "underlying" in front of "platform software"?
<maryjom> DRAFT RESOLUTION: Remove "Underlying" from the definition of "keyboard interface" and SC 2.1.1 Note 1, as proposed.
bruce_bailey: Removing underlying as an adjective before platform.
<PhilDay> +1
<bruce_bailey> +1
<ChrisLoiselle> uno
<GreggVan> +1
<FernandaBonnin> +1
<ShawnT> +1
<olivia> +1
<shadi> 0
RESOLUTION: Remove "Underlying" from the definition of "keyboard interface" and SC 2.1.1 Note 1, as proposed.
<bruce_bailey> @shadi question from horizontal review was if "underlying platform software" was different from "platform software"
The other part related to this was Q11
Q11. Issue 421 part 1 ('keyboard interface' changes): In definition of 'keyboard interface' and in 2.1.1, "would satisfy the success criterion" is incomplete
ISSUE: w3c/
<bruce_bailey> https://
Proposed changes: https://
These were edits that Mitch noticed - definition of keyboard interface had some challenges
Option 0: Original text
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., an interface where the software accepts text or other keystroke input). Platform software may provide device independent input services to applications that enable operation via such a
keyboard interface. Software that supports operation via such platform device independent services would be operable via a keyboard interface and would satisfy the success criterion.
Option 1: Mitch’s proposed changes from the issue
In context of the glossary term ‘keyboard interface’:
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., an interface where the software accepts text or other keystroke input). Platform software may provide device independent input services to applications that enable operation via such a
keyboard interface. Software may support operation via such device- independent services of the platform.
Option 2: An alternate proposal (taking into account some of Gregg’s comments and Mary Jo’s thoughts)
In context of the glossary term ‘keyboard interface’ delete the last sentence.
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., an interface where the software accepts text or other keystroke input). Platform software may provide device independent input services to applications that enable operation via such a
keyboard interface.
Majority preferred option 2 as is. 1 preferred option 1, 1 wanted edits to option 2
Sam: Question for Gregg - why do we need add 'text' to input. Seems a redundant change
[Gregg working on an edit in the Google doc]
GreggVan: You don't accept keyboard input at the keyboard interface - it accepts any text that the system presents at the keyboard interface
<maryjom> POLL: Which do you prefer? 1) Option 2, as-is, 2) Option 3, as edited, or 3) Something else
Option 3: Something else
In context of the glossary term ‘keyboard interface’ delete the last sentence and….
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., the keyboard interface provided by the platform is where the software accepts text or other keystroke input). Platform software may provide device independent input services to applications
that enable operation via such a keyboard interface.
GreggVan: difference between options 2 & 3 are the content after the i.e.
GreggVan: option 3 just explains a bit more
edited version of option 3
Sam: Now that reads (option 3) as if it is different to what the other 2 state.
GreggVan: Correct - now making changes
<Zakim> bruce_bailey, you wanted to ask about kiosk software
Latest version: Option 3: Something elseIn context of the glossary term ‘keyboard interface’ delete the last sentence and….
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., the interface provided by the platform is where the software accepts any text or other keystroke input from a keyboard and any keyboard alternative). Platform software may provide device
independent input services to applications that enable operation via such a keyboard interface.
bruce_bailey: Thought this was about a full time keyboard on a kiosk could pass this criteria - the change in option 3 would mean that a system like this would not pass this criteria
Latest version: Option 3: Something elseIn context of the glossary term ‘keyboard interface’ delete the last sentence and….
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., the interface where the software accepts any text or other keystroke input f which may come from a keyboard and any keyboard alternative). Platform software may provide device independent
input services to applications that enable operation via such a keyboard interface.
Latest version: Option 3: Gregg’s change
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., the interface where the software accepts text or other keystroke input from the platform which may come from a keyboard and any keyboard alternative). Platform software may provide device
independent input services to applications that enable operation via such a keyboard interface.
Option 3: Gregg’s change
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., the interface where the software accepts text or other keystroke input from the platform which may come from a keyboard or from a keyboard alternative). Platform software may provide device
independent input services to applications that enable operation via such a keyboard interface.
<maryjom> POLL: Which do you prefer? 1) Option 2, as-is, 2) Option 3, as edited, or 3) Something else
<GreggVan> +2
2, then 1
<ShawnT> 2
<ChrisLoiselle> 2
<bruce_bailey> 2
<olivia> 2
<Bryan_Trogdon> 2
<Sam> 2
<shadi> 2
RESOLUTION: Incorporate the changes in Option 3 into Note 1 in the definition of 'keyboard interface', as-shown above.
12. Issue 421 part 2 (SC 2.1.1 Keyboard changes): In definition of 'keyboard interface' and in 2.1.1, "would satisfy the success criterion" is incomplete
Proposed content: https://
ISSUE: w3c/
5 preferred option 3, 1 preferred option 0 (no changes)
<bruce_bailey> https://
Use same I.e. as per the last question.
" (i.e., the interface where the software accepts text or other keystroke input from the platform which may come from a keyboard or from a keyboard alternative)"
<ChrisLoiselle> option 3 is fine, or i.e. update for option 4.
<maryjom> POLL: Which do you prefer? 1) Option 3, as-is, 2) Option 4, as-is, or 3) Something else
Option 2: Gregg’s alternate proposal (variation of Mitch’s)
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., an interface where the software accepts text or other keystroke input). Platform software may provide device independent input services to applications that enable operation via such a
keyboard interface. When software supports such a device-independent service of the platform for keyboard input to the software or non-web document, and the software or non-web document’s functionality is made fully operable through input from the service, then this success criterion would be satisfied.
Option 3: An alternate proposal (taking into account Gregg’s issue comment and Mary Jo’s thoughts)
<GreggVan> 2
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., an interface where the software accepts text or other keystroke input). Platform software may provide device independent input services to applications that enable operation via such a
keyboard interface. When software supports such a device-independent service of the platform, and the software or non-web document’s functionality is made fully operable through the service, then this success criterion would be satisfied.
Option 4:Same as 3 but with new i Something else
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., the interface where the software accepts text or other keystroke input from the platform which may come from a keyboard or from a keyboard alternative). Platform software may provide device
<shadi> 2
<GreggVan> 2
<ChrisLoiselle> 2
<ShawnT> 2
<Bryan_Trogdon> 2
independent input services to applications that enable operation via such a keyboard interface. When software supports such a device-independent service of the platform, and the software or non-web document’s functionality is made fully operable through the service, then this success criterion would be satisfied.
<olivia> 2
<bruce_bailey> 2
2
<FernandaBonnin> 2
corrected copy of option 4:
Option 4:Same as 3 but with new i .e.
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., the interface where the software accepts text or other keystroke input from the platform which may come from a keyboard or from a keyboard alternative). Platform software may provide device
independent input services to applications that enable operation via such a keyboard interface. When software supports such a device-independent service of the platform, and the software or non-web document functionality is made fully operable through the service, then this success criterion would be satisfied.
<Sam> 2
<PhilDay> s/I Something else/i.e.
Option 4:Same as 3 but with new i.e.,
Note 1 (Added): Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., the interface where the software accepts text or other keystroke input from the platform which may come from a keyboard or from a keyboard alternative). Platform software may provide device
independent input services to applications that enable operation via such a keyboard interface. When software supports such a device-independent service of the platform, and the software or non-web document functionality is made fully operable through the service, then this success criterion would be satisfied.
RESOLUTION: Incorporate Option 4 changes into SC 2.1.1, as posted in the minutes above, as-is.
2. Issue 465 Part 3 (SC 3.3.8): Seeking clarity for key term 'underlying platform software'
Proposed content: https://
ISSUE: w3c/
Results: https://
4 preferred option 1, 1 preferred option 2, 2 said something else
<bruce_bailey> i don't understand Mike Pluke's comment back to me in survey
<GreggVan> ack
bruce_bailey: We have to look in context - it is confusing
[Mary Jo pulling up latest editor's draft content]
Content from editor's draft, notes for 3.3.8 accessible authentication:
NOTE 1
"Object recognition" and "Personal content" may be represented by images, video, or audio.
NOTE 2
Examples of mechanisms that satisfy this criterion include:
support for password entry by password managers to reduce memory need, and
copy and paste to reduce the cognitive burden of re-typing.
NOTE 3 (ADDED)
If the non-web software is an application, passwords used to unlock the underlying platform software are out of scope for this requirement as these are not up to a software application’s author.
NOTE 4 (ADDED)
There are cases where non-web software has an authentication process and no alternative or assistance mechanism is feasible, for example when entering a password when starting, powering on / turning on an ICT (device or otherwise). In such situations, it may not be possible for the non-web software to meet this success criterion.
NOTE 5 (ADDED)
See also the Comments on Closed Functionality.
bruce_bailey: the opening sentence is not written well.
mitch11: Overly technical, we didn't define what is meant by application - "a software that is not a platform software"
<bruce_bailey> +1 to "too subtle"
GreggVan: The word "underlying" is needed to differentiate between browser (platform software) and operating system (underlying platform software)
<bruce_bailey> the phrase "if the non-web software is an application" is the same as "if the software is software"
Proposal is to change NOTE 3
<Zakim> bruce_bailey, you wanted to ask if "application" is defined term ?
bruce_bailey: Do we define the term "application"?
maryjom: No, we do not have it as a separate term
[Bruce to work on proposal option 3 for this question]
3. Issue 465 Part 4 (Issue answer): Seeking clarity for key term 'underlying platform software'
Proposed answer: https://
5 said answer was sufficient as is, 1 with edits, 1 preferred something else
<mitch11> Sorry, I joined only briefly today, and now I need to drop. Regrets for tomorrow's working session.
Please just let us know before you drop, so we know how many people we still have
<FernandaBonnin> * I need to drop
<ShawnT> I need to drop, thank you very much
Sam: also has to drop
<maryjom> POLL: Which do you prefer as the answer to Issue 465? 1) Option 1: without edits, 2) Option 1: with edits, or 3) Something else?
2, would also accept 1
<GreggVan> 2
<bruce_bailey6> 2
<ChrisLoiselle> 2
<olivia> 2
Option 1: Proposed answer
Thank you for your review and comment.
In the editor’s draft, the Task Force has already made some changes to the non-web software notes in SCs 2.5.1, 2.5.2, and 2.5.7 due to Issue 414. We are wondering if the changes we have already made also address the concern expressed in this issue. See:
2.5.1 Pointer Gestures (non-web software branch) (Notes 3 and 4)
2.5.2 Pointer Cancellation (non-web software branch) (Notes 5 and 6)
2.5.7 Dragging Movements (non-web software branch) (Notes 3 and 4)
The Task Force also analyzed and discussed other uses of ‘underlying platform software’ and feel that there is no need for a key term ‘underlying’ or ‘underlying platform software’ (instead of just “Platform software” by itself) for the following reasons:
The visual formatting of word replacements (a W3C CSS document styling for INS markdown) may have made it visually appear that the phrase “underlying platform software” is a key term, but it is not. Unfortunately the W3C markup for inserted text (a dotted green underline) can be hard to discern from the medium gray underline used for the link
to key terms (so insertion markup looks like key term markup)
We are using “underlying” the Mirriam-Webster dictionary meaning which is “lying beneath or below”. Using “underlying” is simply to indicate that there are software layers with the application software being in a layer above the platform layer. There can even be multiple layers of platform software.
We also think that the changes made for Issue 414 clarifies the related Notes 3 & 4 in SCs 2.5.1 and 2.5.7, and Notes 5 & 6 in SC 2.5.2 by moving “user agent” to the latter note regarding platform software. “User agent” is given as an example in the definition of “platform software”, as well as a statement that there may be multiple
layers of platform software. We think these changes brought the notes into alignment with the definition.
For SC 3.3.8 Accessible Authentication, we don’t think any change is needed, as the verbiage is consistent with the 2.5.x SC mentioned above.
For SC 2.1.1 Keyboard and the glossary term “keyboard interface,” the task force agreed that a change to remove “underlying” is reasonable. These instances are both clear without that word.
You can read the changed text in-context in the document using the following links:
Applying SC 2.1.1 Keyboard to Non-Web Documents and Software (See Note 1.)
Applying “keyboard interface” to Non-Web Documents and Software (See Note 1.)
Please respond to let us know that this sufficiently addresses your comment.
<GreggVan> NOTE 3: Any passwords used to unlock platform software running below the non-web software are out of scope for this requirement since these are not under control of the non-web software’s author
RESOLUTION: Answer Issue 465, as edited in the meeting and posted above in the minutes.
2. Issue 465 Part 3 (SC 3.3.8): Seeking clarity for key term 'underlying platform software' (returning to previous question)
Proposed changes: https://
Results: https://
<bruce_bailey> +1
OPTION 4 (Gregg created on call from discussion)
NOTE 3: Any passwords used to unlock platform software running below the non-web software are out of scope for this requirement since these are not under control of the non-web software’s author.
Full list of options:
Option 1: No change
(NOTE: This option is consistent with the decision on 22 Aug. to not change 2.5.1, 2.5.2, and 2.5.7.)
In SC 3.3.8 Accessible Authentication, the current Note 3 says:
NOTE 3: If the non-web software is an application, passwords used to unlock the underlying platform software are out of scope for this requirement as these are not up to a software application’s author.
Option 2: Make changes similar to option 3 proposed for SC 2.5.1, 2.5.2, and 2.5.7
NOTE 3: If the non-web software is an application, passwords used to unlock the underlying platform software that sits beneath the software application are out of scope for this requirement as these are not up to a software application’s author.
Option 3: Something else (bruce’s proposal in survey (as option 3, same as Option 2, dropping leading clause))
NOTE 3: Passwords used to unlock the underlying platform software are out of scope for this requirement. Such passwords are not under the control of the non-web software.
OPTION 4 (Gregg created on call from discussion)
NOTE 3: Any passwords used to unlock platform software running below the non-web software are out of scope for this requirement since these are not under control of the non-web software’s author.
<maryjom> POLL: Which option do you prefer? 1-4 or 5) Something else
<GreggVan> 4
<bruce_bailey> 4
4, then 3
<ChrisLoiselle> 4
<olivia> 4
OPTION 4 (Gregg created on call from discussion)
NOTE 3: Any passwords used to unlock platform software running below the non-web software are out of scope for this requirement since these are not under control of the non-web software’s author.
Question on the word "below"
Discussion on underlying -we are using it in other SCs
<bruce_bailey> Any passwords used to unlock underlying platform software (running below the non-web software) are out of scope for this requirement since these are not under control of the non-web software’s author.
<maryjom> POLL: Which do you prefer? 1) No change or 4) Option 4, as edited.
4, with bruce's edits
Option 5: Bruce’s edit
Any passwords used to unlock underlying platform software (running below the non-web software) are out of scope for this requirement since these are not under control of the non-web software’s author.
OPTION 4 (Gregg created on call from discussion)
NOTE 3: Any passwords used to unlock platform software running below the non-web software are out of scope for this requirement since these are not under control of the non-web software’s author.
<maryjom> POLL: Which do you prefer? Option 4 or Option 5?
5
<bruce_bailey> 5
<GreggVan> 5
<ChrisLoiselle> 5 , i believe :)
<olivia> 5
RESOLUTION: Incorporate the changes in Option 5 into SC 3.3.8 Accessible Authentication, as-is (also posted above in the minutes).
4. Issue 466: Closed functionality list - suggested additions
ISSUE: w3c/
Proposed changes: https://
Results: https://
5 preferred option 2 as is, 1 had an alternative
This came from horizontal review - they had some examples they wanted added to closed.
Our proposal is only to add to the definition, not to the comments (as we didn't actually discuss these examples when we drafted the comments)
Proposal 2: Incorporate suggested examples from Issue 466
[Examples excerpt from the Key Terms section on “closed functionality (as used by WCAG2ICT)”]
Example: Examples of technology that may have closed functionality include but are not limited to:
self-service transaction machines or kiosks — examples include machines used for retail self-checkout, point of sales (POS) terminals, ticketing and self-check-in, and Automated Teller Machines (ATMs).
telephony devices such as internet phones, feature phones, smartphones, and phone-enabled tablets
educational devices such as interactive whiteboards and smart boards
entertainment technologies including gaming platforms or consoles, smart TVs, set-top boxes, smart displays, smart speakers, smart watches, and tablets
an ebook reader or standalone ebook software that allows assistive technologies to access all of the user interface controls of the ebook program (open functionality) but does not allow the assistive technologies to access the actual content of the book (closed functionality).
medical devices such as digital blood pressure monitors, glucose meters, or other wearable devices
an operating system that makes the user provide login credentials before it allows any assistive technologies to be loaded. The login portion would be closed functionality.
other technology devices, such as printers, displays, and Internet of Things (IoT) devices.
[Examples excerpt from the Comments on Closed Functionality section]
Example: In developing guidance for closed functionality, the task force has considered specific examples of ICT that historically have been partially or fully closed to assistive technologies:
self-service transaction machines or kiosks (e.g. retail self-checkout, point of sales (POS) terminals, and Automated Teller Machines (ATMs))
telephony devices (e.g. internet phones, feature phones, and smartphones)
entertainment technologies (e.g. smart TV, set-top box, smart watches)
ebook reader
computer that is locked down due to a policy so that users may not adjust settings or install software
other technology devices (e.g. printers, displays, and Internet of Things (IoT) devices).
[Gregg’s proposed edit] telephony devices such as internet phones, feature phones, smartphones, and phone-enabled tablets (which may include AT in their systems but are themselves often closed for other software assistive technologies)
only change is to add items in parentheses
maryjom will follow up with Gregg on this inclusion
… or exclusion
<maryjom> POLL: 1) Add Proposal 2 as-is 2) with Gregg's edits or 3) something else
1
<bruce_bailey> 1
<olivia> 1
<ChrisLoiselle> 1
RESOLUTION: Incorporate Proposal 2 (new examples) as originally proposed in Option 2 into the definition of 'closed functionality'.
5. Issue 464: Suggest slight clarification of audience and outcomes
ISSUE: w3c/
Proposed content: https://
All preferred option 3 (2 as is, 5 with edits).
Edit was to remove the addition of "commonly expressed by the acronym, POUR"
only add the sentence "Developers are also strongly encouraged to obtain testing input from persons with disabilities using applications and content. "
Option 3: Edit APA recommendations, resulting in minor changes to Background & Guidance sections
Additions to current WCAG2ICT content are shown in yellow highlight.
[Background section]
This document is an update to a W3C Working Group Note to incorporate new guidelines, success criteria, and definitions added in WCAG 2.1 and 2.2.
Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT), approved in September 2013, described how WCAG 2.0 could be applied to non-web documents and software. WCAG2ICT was organized to mirror WCAG's sections: Perceivable, Operable, Understandable, and Robust, commonly expressed by the acronym, POUR. WCAG2ICT
clarified when and how WCAG success criteria shcould be applied to non-web documents and software. Some were applicable without modification and some were applicable with edits and/or notes. Glossary terms were also reviewed. Level AAA success criteria were not addressed in the 2013 WCAG2ICT Working Group Note.
[Guidance section]
This document provides informative guidance (guidance that is not normative and that does not set requirements) with regard to the interpretation and application of Web Content Accessibility Guidelines (WCAG) to non-web information and communications technologies (ICT). This document is a Working Group Note (in contrast to WCAG 2.0, WCAG 2.1, and
WCAG 2.2, which are W3C Recommendations). Specifically, this document provides informative guidance on applying WCAG 2.0, 2.1, and 2.2 Level A and AA success criteria to non-web ICT, specifically to non-web documents and software.
NOTE 1: Hereafter, the use of WCAG 2 means all WCAG 2.x versions — 2.0, 2.1, and 2.2.
This document is intended to help clarify how to use WCAG 2 to make non-web documents and software more accessible to people with disabilities. Addressing accessibility involves addressing the needs of people with auditory, cognitive, neurological, physical, speech, and visual impairments, as well as accessibility needs of people due to the effects
of aging. Although WCAG 2 addresses some user needs for people with cognitive and learning disabilities as well as mental health related disabilities, following the WCAG supplement Making Content Usable for People with Cognitive and Learning Disabilities is recommended for non-web ICT to address the user needs of these groups. Developers are also
strongly encouraged to obtain testing input from persons with disabilities using applications and content.
Only change is adding the last sentence: Developers are also strongly encouraged to obtain testing input from persons with disabilities using applications and content.
And change should to could
<olivia> I will have to drop after this one
RESOLUTION: Incorporate the new sentence regarding developers and change "should" to "could", but not include "POUR" phrasing, as shown above in the minutes to the Background and Guidance sections.
<GreggVan> +1
<shadi> +1 (from irc only)
<GreggVan> it is ok phil no need
<bruce_bailey> https://
6. Issue 463 (Issue answer): Programmatically determine the language of text
ISSUE: w3c/
Proposed content: https://
Another question from horizontal review. All liked the proposed answer; Gregg had some additions
<bruce_bailey> https://
Gregg's comment: I would add something like this-- what we have is a bit ambigous. states what but not clearly why
Note that the definition of Heuristic makes it clear it is an inaccurate approximation " not fully optimized, perfected, or rationalized, but is nevertheless "good enough" as an approximation or attribute substitution". Programmatically determined means that is can be exactly determined by software including assistive technologies. Examples of ways
to do this today include markup, attributes or technology-specific data structures. Other methods may be possible in the future but they must be accurate and reliable.
Gregg agrees with bruce - correcting somebody on their use of the term heuristic could come across badly, so just drop that part
Gregg's revised comment:
Programmatically determined means that is can be exactly determined by software including assistive technologies. Examples of ways to do this today include markup, attributes or technology-specific data structures. Other methods may be possible in the future but they must be accurate and reliable.
Brief discussion of possible future solutions using AI - may not need markup in the future if the browser or software could do it in another way
Content from google doc:
Draft Answer Proposal 1: Not making changes, this is WCAG text
@xfq Thank you for your comment. To answer your questions:
>Does "programmatically determined" mean heuristic detection of language?
No, this does not pertain to auto-detection. Programmatically determined means determined by software from author-supplied data, per the definition of ‘programmatically determined’ in WCAG. Examples are provided indicating what would be considered author-supplied data that user agents and assistive technologies can extract and present to the
user (e.g. markup language elements and attributes or technology-specific data structures).
>Why do these exceptions exist?
These exceptions were defined by WCAG 2.0 (and have persisted without change ever since).
Note that the WCAG2ICT TF has not modified these exceptions in any way. The only changes WCAG2ICT made to the language for 3.1.2 Language of Parts is the word substitution exchanging web-centric terms with terms more applicable to non-web technologies. Per the WCAG2ICT Task Force’s scope of work, we are unable to change the meaning of a
requirement by modifying normative language, including the exceptions.
If there is a concern with the exceptions or with the definition of “programmatically determined,” we recommend that you raise an issue in the WCAG repository. The WCAG2ICT repository is limited to comments on the interpretation, word substitutions, and notes describing how to apply WCAG in an non-web context.
Unless the WCAG language gets changed by the Accessibility Guidelines Working Group (AGWG), the WCAG2ICT Task Force cannot make any further modifications to them in the WCAG2ICT Group Note.
<bruce_bailey> i am okay with adding Gregg 2nd sentence to response. (at minute 11:33)
Edit from Gregg: @xfq Thank you for your comment. To answer your questions:
>Does "programmatically determined" mean heuristic detection of language?
Programmatically determined means determined by software from author-supplied data, per the definition of ‘programmatically determined’ in WCAG. Examples are provided indicating what would be considered author-supplied data that user agents and assistive technologies can extract and present to the user (e.g. markup language elements and
attributes or technology-specific data structures today and possibly direct determination by software in the future).
<Zakim> PhilDay, you wanted to ask if we still have a quorum
Draft Answer Proposal 1: Not making changes, this is WCAG text
@xfq Thank you for your comment. To answer your questions:
>Does "programmatically determined" mean heuristic detection of language?
No, this does not pertain to auto-detection. Programmatically determined means determined by software from author-supplied data, per the definition of ‘programmatically determined’ in WCAG. Examples are provided indicating what would be considered author-supplied data that user agents and assistive technologies can extract and present to the
user (e.g. markup language elements and attributes or technology-specific data structures).
>Why do these exceptions exist?
These exceptions were defined by WCAG 2.0 (and have persisted without change ever since).
Note that the WCAG2ICT TF has not modified these exceptions in any way. The only changes WCAG2ICT made to the language for 3.1.2 Language of Parts is the word substitution exchanging web-centric terms with terms more applicable to non-web technologies. Per the WCAG2ICT Task Force’s scope of work, we are unable to change the meaning of a
requirement by modifying normative language, including the exceptions.
If there is a concern with the exceptions or with the definition of “programmatically determined,” we recommend that you raise an issue in the WCAG repository. The WCAG2ICT repository is limited to comments on the interpretation, word substitutions, and notes describing how to apply WCAG in an non-web context.
Unless the WCAG language gets changed by the Accessibility Guidelines Working Group (AGWG), the WCAG2ICT Task Force cannot make any further modifications to them in the WCAG2ICT Group Note.
OPTION 2: Draft answer proposal 2 - Gregg’s edits
@xfq Thank you for your comment. To answer your questions:
>Does "programmatically determined" mean heuristic detection of language?
Programmatically determined means determined by software from author-supplied data, per the definition of ‘programmatically determined’ in WCAG. Examples are provided indicating what would be considered author-supplied data that user agents and assistive technologies can extract and present to the user (e.g. markup language elements and
attributes or technology-specific data structures today and possibly direct determination by software in the future).
>Why do these exceptions exist?
These exceptions were defined by WCAG 2.0 (and have persisted without change ever since).
Note that the WCAG2ICT TF has not modified these exceptions in any way. The only changes WCAG2ICT made to the language for 3.1.2 Language of Parts is the word substitution exchanging web-centric terms with terms more applicable to non-web technologies. Per the WCAG2ICT Task Force’s scope of work, we are unable to change the meaning of a
requirement by modifying normative language, including the exceptions.
If there is a concern with the exceptions or with the definition of “programmatically determined,” we recommend that you raise an issue in the WCAG repository. The WCAG2ICT repository is limited to comments on the interpretation, word substitutions, and notes describing how to apply WCAG in an non-web context.
Unless the WCAG language gets changed by the Accessibility Guidelines Working Group (AGWG), the WCAG2ICT Task Force cannot make any further modifications to them in the WCAG2ICT Group Note.
<Zakim> bruce_bailey, you wanted to ask if any concerns asking @xfp to file an issue on WCAG2-Issues (backlog) ?
bruce_bailey: happy with edits. Could direct this to the backlog - maybe it should be added to WCAG2 backlog
maryjom: already in the draft response
Revised option 2: OPTION 2: Draft answer proposal 2 - Gregg’s edits
@xfq Thank you for your comment. To answer your questions:
>Does "programmatically determined" mean heuristic detection of language?
Programmatically determined means determined by software from author-supplied data, per the definition of ‘programmatically determined’ in WCAG. Examples are provided indicating what would be considered author-supplied data that user agents and assistive technologies can extract and present to the user (e.g. markup language elements and
attributes or technology-specific data structures today and possibly direct determination by software in the future).
>Why do these exceptions exist?
These exceptions were defined by WCAG 2.0 (and have persisted without change ever since).
Note that the WCAG2ICT TF has not modified these exceptions in any way. The only changes WCAG2ICT made to the language for 3.1.2 Language of Parts is the word substitution exchanging web-centric terms with terms more applicable to non-web technologies. Per the WCAG2ICT Task Force’s scope of work, we are unable to change the meaning of a
requirement by modifying normative language, including the exceptions.
If there is a concern with the exceptions or with the definition of “programmatically determined,” we recommend that you raise an issue in the WCAG repository. The WCAG2ICT repository is limited to comments on the interpretation, word substitutions, and notes describing how to apply WCAG in an non-web context. You could also refer to
Understanding WCAG 2.2 for SC 3.1.2 Language of Parts.
Unless the WCAG language gets changed by the Accessibility Guidelines Working Group (AGWG), the WCAG2ICT Task Force cannot make any further modifications to them in the WCAG2ICT Group Note.
<maryjom> DRAFT RESOLUTION: Answer Issue 463 using Option 2, as-is. (and as also posted above in the minutes).
<ChrisLoiselle> Zakim gives Elon 2 minutes
<PhilDay> +1
<bruce_bailey> +1
<ChrisLoiselle> +1
<GreggVan> +1
RESOLUTION: Answer Issue 463 using Option 2, as-is. (and as also posted above in the minutes).
7. Issue 473 (Issue answer): Definitions and explanations for “Set of Documents” and “Set of Software Programs” produces strange corner cases that should be addressed or explained
We shall continue next Thursday from Q7 onwards.
We may need to extend next week as well - hopefully we can finish all questions.
Reminder: if anyone has not completed the survey, please do that ASAP
The intent would be to then get the changes made, and issue as a final note
Survey is still open for another week
Daniel kindly agreed to move questions that have not yet been covered to front of survey for ease of use next week
Then add extra marker to say that all issues after this question are now closed...
maryjom: will create PRs based on the resolutions made today