See also: IRC log
<trackbot> Date: 11 June 2015
http://www.w3.org/WAI/UA/work/wiki/Use_Cases_for_UAAG_Applicability
open item 1
<jeanne> https://www.w3.org/WAI/UA/work/wiki/Comments_%26_Responses_30_April_2015
Proposal: 4.1.4 DOMs Programmatically Available as fallback:
If the user agent accessibility API does not provide sufficient information to one or more platform accessibility services, then Document Object Models (DOM), must be made programmatically available to assistive technologies. (Level A)
Several screenreader vendors say one particular browser has an insufficient accessibility API, and they need DOM access
discussion of technical work arounds for lack of DOM access
<jeanne> https://www.w3.org/WAI/UA/work/wiki/Comments_%26_Responses_30_April_2015
ja: +1 on proposal
<jeanne> +1 to proposal
<Greg> +1
RESOLUTION: change 4.1.4 to be DOMs Programmatically Available as fallback: If the user agent accessibility API does not provide sufficient information to one or more platform accessibility services, then Document Object Models (DOM), must be made programmatically available to assistive technologies. (Level A)
Close item 1
<jeanne> 4.1.4. Intent proposed: Assistive technologies need all possible information. Applications such as user agents and assistive technologies use a combination of DOMs, accessibility Application Programming Interfaces (API), native platform APIs, and hard-coded heuristics to provide an accessible user interface and accessible content. While most assistive technology vendors prefer to use the AAPIs, if
<jeanne> the AAPI cannot provide enough access to the content, then It is the user agent's responsibility to expose the DOM to assistive technology.
<jeanne> revision: Assistive technologies need all possible information. Applications such as user agents and assistive technologies use a combination of DOMs, Accessibility Application Programming Interfaces (AAPI), native platform APIs, and hard-coded heuristics to provide an accessible user interface and accessible content. While most assistive technology vendors prefer to use the AAPIs, if the AAPI
<jeanne> cannot provide enough access to the content, then It is the user agent's responsibility to expose the DOM to assistive technology.
<Greg> Even though a UA developer may think that they've exposed all necessary information through the AAPI, it is extremely difficult to be sure that the coverage is indeed complete until a screen reader actually tries to rely on it. That is why developers are strongly encouraged to provide redundant information through as many mechanisms as possible, including the DOM.
ok
gl: add swapping styles between users
ok
<Greg> Re #2, add that we require the ability to copy settings from one system to another, allowing a technical expert to develop the customized style sheet which is then distributed to many end users.
<Greg> Might also add that we've altered the wording to make it clearer that this is not just about style sheets in the CSS-specific meaning, but also includes other mechanisms for that could include graphical approaches that would be easier for the average end user.
ja: so operating systems settings
are high contrast, bounce keys, repeat keys. Font family, size
and color are over ridden by the browser, as are foreground and
background, except for high contrast mode.
... not sure what other OS accessibility settings the UA should
pick up
<Greg> Jim points out that one advantage of requiring accessibility settings be at the browser level (rather than only at the OS level) is that 2.7.5 recommends browser settings be transferrable between systems, while we cannot say the same for OS settings.
for the UA UI it should respect the OS settings
ok
ok
<Greg> Our response to Cynthia's comment on 1.3.1 could say that 1.3.1 does not require the UA to provide it's own UI for adjusting the settings. If the UA wants to simply respect user-settings from the OS level, that is fine. However, if the OS does not allow the user to set one of the listed values (e.g. distinguishing visited from unvisited links) then the UA would be required to provide its own...
<Greg> ...UI for this user option.
additionally, this can be met through the a user styling mechanism
(aside) in the future we should have an sc that would merge user styles (default for selection, font, etc) with the authors
<Greg> If the UA does not provide an option to pick up default text settings from the OS, it will not block users from accessing any content, it merely makes it a bit more work for the user to configure the UA to have equivalent settings. That extra one-time effort does not seem to be enough to justify making it Level A.
<Greg> That being said, we agree that every browser should provide this option as a convenience.
reference: see response to 2 above
for some users they may have to break a site to get the information.
ok
ok
ok
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: allanj Inferring Scribes: allanj Present: Greg Jim Jeanne Found Date: 11 Jun 2015 Guessing minutes URL: http://www.w3.org/2015/06/11-ua-minutes.html People with action items:[End of scribe.perl diagnostic output]