<scribe> scribe:MaryJo
Beginning to get some comments in the list of correspondence and need to be entered into the system.
<korn> https://www.w3.org/2002/09/wbs/55145/GLOSSARY4/results
Gregg will post a draft of the process on our working group's home page.
<Mike> https://www.w3.org/2002/09/wbs/55145/GLOSSARY4/results
https://www.w3.org/2002/09/wbs/55145/GLOSSARY4/results#xq12
https://www.w3.org/2002/09/wbs/55145/GLOSSARY4/results#xq11
RESOLUTION: Accept programmatically determined link context and text alternative as written.
https://www.w3.org/2002/09/wbs/55145/GLOSSARY4/results#xq1
Proposal was made to replace "Web page" with "electronic document or software".
<korn> +1 to Andi's alternative.
RESOLUTION: Accept the definition ambiguous to users in general with the proposed update.
Proposal was made to add a note to this definition as well as the contrast ratio definition. This is the same text as in the introduction.
<greggvanderheiden> https://sites.google.com/site/wcag2ict/home/definitions-from-glossary/d---relative-luminance
RESOLUTION: Accept definition of relative luminance and contrast ratio in Proposal 1 as written.
<greggvanderheiden> https://sites.google.com/site/wcag2ict/home/definitions-from-glossary/d---contrast-ratio
https://www.w3.org/2002/09/wbs/55145/GLOSSARY4/results#xq3
Proposal was made to add in our note from 2.1.1.
Concern about the term 'keystroke input' which is not defined in WCAG 2.0. May want to define what this means in the software world.
<Mike> 2.1.1 Note: Note: This does not imply that software must directly support OR PROVIDE a keyboard or "keyboard interface". UNDERLYING Platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.
In software world, focus doesn't always move via keystroke input.
Keystroke input is critical for discrete non-time dependent encoded input. By mapping gestures to a keyboard command, a user could attach a keyboard and use the software or device.
The concern is with the word 'keyboard' as opposed to using 'encoded input'.
Input method should allow various input modalities to accomodate the various disability types and the devices they use.
Currently devices have a method to accept keystrokes. There will always be a user group that needs the ability to use a keyboard for navigation and/or input - especially users with multiple disabilities.
On Android, switches actually drive the use of the device using the accessibility APIs rather than by mapping it to keyboard input.
Tecla is a switch that uses the API.
It uses a group of standard verbs/actions to operate functions in the application.
<korn> "This does not imply that software must directly support a keyboard or "keyboard interface". Nor does it imply that software must provide a soft keyboard. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply."
<greggvanderheiden> https://sites.google.com/site/wcag2ict/home/definitions-from-glossary/d---keyboard-interface
RESOLUTION: Accept the definition of keyboard interface as written in proposal 1.
<greggvanderheiden> https://sites.google.com/site/wcag2ict/home/definitions-from-glossary/d---supplemental-content
<greggvanderheiden> https://sites.google.com/site/wcag2ict/home/definitions-from-glossary/d---label
RESOLUTION: Accept label and supplemental content as written in proposal 1.
<greggvanderheiden> https://sites.google.com/site/wcag2ict/home/definitions-from-glossary/d---name
<greggvanderheiden> https://sites.google.com/site/wcag2ict/home/definitions-from-glossary/d---role
RESOLUTION: Accept name and role as written in proposal 1.
https://www.w3.org/2002/09/wbs/55145/GLOSSARY4/results#xq9
This term is used in 3.2.4.
Will address this later in the meeting if there's time.
https://www.w3.org/2002/09/wbs/55145/GLOSSARY4/results#xq5
There are concerns with high resolution screens and small devices. WCAG did think about these when making this SC.
For high resolution screens, the user can change your screen resolution or use magnification to resolve how small the text appears.
For small screens, users won't be purchasing the device to view web content.
Someone with low vision should purchase larger devices for this purpose.
Note 4 doesn't always apply to non-web ICT, but isn't wrong as it is written.
The points and typography description is not how software uses it in practice. However, point sizes do map to a particular size measurement.
We discussed note 4 and decided it doesn't invalidate the definition, but is occasionally applicable to non-Web ICT.
RESOLUTION: Accept large scale text as written.
https://www.w3.org/2002/09/wbs/55145/2012-09-06/results
<Mike> Content primarily intended to create a sensory experience often cannot be fully captured in text. For example, a flute solo can be played to describe the tonal quality of the performer, or a painting is displayed to depict the style of a painter. Text alternatives should at least identify the non-text content with a descriptive label and where possible, additional descriptive text to describe the sensory qualities intended to convey to the user. If the reason
for including the content in the page is known and can be described it is helpful but not required to include that information in the text alternative.
RESOLUTION: Accept addition to WCAG intent for 1.1.1 Non-text Content proposed above as updated in the meeting.
<greggvanderheiden> Content primarily intended to create a sensory experience often cannot be fully captured in text. For example, a flute solo by an artist may be provided for the specific tonal quality of the performer, or a painting is displayed to depict the style of a painter.
<greggvanderheiden> Text alternatives should at least identify the non-text content with a descriptive label and where possible, additional descriptive text to describe the sensory qualities intended to convey to the user. If the reason for including the content in the page is known and can be described it is helpful but not required to include that information in the text alternative.
<greggvanderheiden> oops too late
<greggvanderheiden> no problem
Not discussed
Revisit same functionality definition next meeting.