See also: IRC log
<trackbot> Date: 28 May 2015
open item 1
https://lists.w3.org/Archives/Public/w3c-wai-ua/2015AprJun/0046.html
no change to 4.1.1, 4.1.3, 4.1.5
gl: remove bullet change state/value notification because it is mentioned in the body of the SC
js: but they might miss it if not in the list
gl: concerned about "relationships" should (aria) be an example
js: make it specific to aria. as greg says 'relationships' is very broad
gl: if we make specific then if they don't do aria then they don't have to do anything?
ja: is covered in 1.10.1
<Greg> 1.10.1 requires that explicitly defined relationships (e.g. that image A labels button B) are made available directly to the user, but Guideline 4 fails to require the same information be made available to assistive technology (e.g. screen readers). That seems like a major oversight.
ja: keep relationships broad use (e.g. ARIA) and reference 1.10.1
<Greg> We could add a bullet to 4.1.2 that said "Relationships per 1.10.1 "Show Related Elements".
<Greg> Related, should 1.10.1 also mention ARIA explicitly?
<Greg> We should attempt to keep the wording consistent, e.g. if we add relationships to 4.1.2 we should say "explicitly-defined relationships in content", the phrase we use in 1.10.1.
ja: cross reference 1.10.1 and 4.1.2
<Greg> Discussing whether 4.1.2 should have a bullet for "ARIA relationships" or the broader "Explicitly-defined relationships (e.g. ARIA)". The latter is closer to 1.10.1. Or, should it be "Explicitly-defined relationships in content (e.g. ARIA)", omitting UA UI?
<Greg> In each of the latter two cases, the phrase "Explicitly defined relationships" is taken from 1.10.1.
ja: +1 to Explicitly-defined relationships (e.g. ARIA)
js: concern about broadness, trying to think of use cases
proposal:
<jeanne> Explicitly defined relationships (e.g. ARIA relationships [ARIA 1.0])
4.1.2 Expose Basic Properties: For all user interface components (including UA user interface, rendered content, and generated content) the user agent makes available the following properties and any change notifications via a platform accessibility service: (Level A)
Name
Role
State
Value
Selection
Focus
Bounding dimensions and coordinates
Font family of text
Font size of text
Foreground and background color for text
Highlighting
Keyboard commands
Explicitly defined relationships (e.g. ARIA relationships [ARIA 1.0])
Caret position
@@cross reference 1.10.1 and 4.1.2
RESOLUTION: Accept 4.1.2 as above.
proposal:
4.1.4 DOMs Programmatically Available as fallback:
If the user agent does not implement one or more platform accessibility services, then Document Object Models (DOM), must be made programmatically available to assistive technologies. (Level A)
RESOLUTION: delete 4.1.6 (merged with 4.1.2)
gl: not thrilled
<Greg> I'm concerned because one screen reader developer indicated that some applications implement platform API but so badly that the AT must fall back on DOM access. Similarly, a second screen reader developer indicated that for a range of user agents they need to rely on the DOM to pick up individual details that the applications omits or exposes incorrectly through the platform API.
<Greg> In those cases, if we say that the browser making any token use of the platform API then need not provide DOM access for filling in the gaps, the SC accomplishes very little.
<Greg> I am unclear on how Microsoft Edge will prevent extensions from accessing the DOM and bridging the information to external AT. Perhaps that's only because they will not have Chrome extensions supported in their first release?
<jeanne> 4.1.4 Make content programmatically Available: The user agent makes all content programmatically available to the assistive technology, either through implementation of a platform accessibility API or, if not available, by exposing the DOM.
<Greg> Keep in mind that the SC as it stands does not requires a UA to implement a DOM, or implement it where it's not already implemented for their own needs. It only says that where they implement one, it should be available to AT for taking advantage of it.
js: seems that browsers are getting rid of the DOM, old technology.
gl: but that would break all of JavaScript
js: is writing contacts asking about dom vs api, how javascript works with out dom
<Greg> My takeaways from last week's call with Rich and Doug was that the DOM will have an increasing number of holes (e.g. webapps that draw directly into a grid element, and also the use of injected or generated content, all of which won't be reflected in the DOM). Thus, AT should not rely entirely on the DOM. However, it does not mean that DOM access cannot help the AT fill in gaps. Similarly,...
<Greg> ...DOM access may be superseded by new API that is more effective and complete for automated testing (e.g. WebDriver). If that's the case, perhaps what we should be requiring is not that UA should expose the DOM to AT but that it should expose *ALL* API that it already supports that provide access to the content (including but not limited to the DOM).
whatwg is working on DOM https://dom.spec.whatwg.org/
http://accessibility.linuxfoundation.org/a11yspecs/atspi/adoc/a11y-dom-apis.html
ja: table this for now. revisit 4.1.4 next week with new information.
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) Succeeded: s/Mike Hill of Dolphin/one screen reader developer/ Succeeded: s/Doug Geoffray of AI Squared/a second screen reader developer/ Succeeded: s/that provides/that provide/ No ScribeNick specified. Guessing ScribeNick: allanj Inferring Scribes: allanj Present: Jim Jeanne Greg Kim Found Date: 28 May 2015 Guessing minutes URL: http://www.w3.org/2015/05/28-ua-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]