See also: IRC log
<trackbot> Date: 12 July 2012
<kford> Note, we think this might really be action 699
<kford> Kim, Greg)
<kford> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0028.html
<jeanne> chair: Kelly
<scribe> scribe: Jan
https://www.w3.org/2002/09/wbs/36791/20120710/results#xq1
KF: Kim's change seems to make sense.
"relative to the current position"
KF: Simon has more comments...
JR: I like Greg's change, its very clear
Greg's version ""Relative time units define time intervals for navigating media relative to the current point (e.g. move forward 30 seconds). When interacting with a time-based media presentation, a user may find it beneficial to move forward or backward via a time interval relative to their current position. For example, a user may find a concept unclear in a video lecture and elect to skip...
scribe: back 30 seconds from the
current position to review what had been described. Relative
time units may be preset by the user agent, configurable by the
user, and/or automatically calculated based upon media duration
(e.g. jump 5 seconds in a 30-second clip, or 5 minutes in a
60-minute clip). Relative time units are distinct from absolute
time values such as the 2 minute mark, the half-way...
... point, or the end."
SH: It's fine for me
MH: I'd be fine with Greg's version
JS: I'm good
KF: Are we good.
Resolved: Use wording: "Relative time units define time intervals for navigating media relative to the current point (e.g. move forward 30 seconds). When interacting with a time-based media presentation, a user may find it beneficial to move forward or backward via a time interval relative to their current position. For example, a user may find a concept unclear in a video lecture and elect...
scribe: to skip back 30 seconds
from the current position to review what had been described.
Relative time units may be preset by the user agent,
configurable by the user, and/or automatically calculated based
upon media duration (e.g. jump 5 seconds in a 30-second clip,
or 5 minutes in a 60-minute clip). Relative time units are
distinct from absolute time values such as the 2 minute mark,
the...
... half-way point, or the end.
KF: Moving on to 1.1.3:
https://www.w3.org/2002/09/wbs/36791/20120710/results#xq2
Greg: The reference may be 1.8.3...
GL: Also felt like the wording of
(a) includes positionning
... Maybe will go away when we make it a full sentence
MH: I just thought it would read as not clear which viewport...
GL: Well think about youtube...Flash is the nested user agent
It can't put stuff outside into the containing user agents viewport
GL: The viewport might be the whole window or not
<Greg> In my comments I suggested "(b) Position the media alternative as a viewport (e.g. so that it does not obscure the primary time-based media or its controls)."
GL, JR: Discussing (b) ...the non-overlapping
JR: Could it be implying floating?
MH: We want to provide a few options
GL: Like?
MH: If constrained to captions within the viewport....to restrictive
GL: Sometimes nested user agents don't have the room
<kford> JR: Do we need to have a recongized concept in here?
JR: Same with mobile
devices
... What about open captions?
GL: Probably handled by defn
MH: It's not an "alternative"
KF: So does someone want to take it for more edits?
MH: I will take it back for one more round
KF: Moving to proposed 4.1.1
https://www.w3.org/2002/09/wbs/36791/20120710/results#xq3
GL: This one makes me nervous...not ready to approve it yet...so complicatred
MH: Can you explain?
GL: So the plan is to replace platform accessibility architecture with platform accessibility services?
KF: Yes
GL: What's with brackets...
JR: ATAG changed the wording to...."expose accessibility information through"
GL: Better to be specific...but
these services do three things
... let accessibility aid query info, notify accessibility aids
when things change, let accessibility aids trigger actions
JR: Is that all access APIs?
GL: No, but where uit exists, it
must be supported
... It should support the full range of services provided by
the platform architecture
KF: Can we table this for a minute...
Jumping to: https://www.w3.org/2002/09/wbs/36791/20120710/results#xq4
MH: I think Kim's intent text is good with one change...
<mhakkinen> People who use assistive technologies such as screen readers may find that a technology isn't fully compatible with a Web browser, or that the browser doesn't accessibly render content authored in compliance with WCAG. This causes information loss and inconvenience. When this happens, users with disabilities will benefit from being able to easily file a report with the user agent vendor to report the incompatibility, similar the way users can
<mhakkinen> file bug reports or provide feedback.
+1
<Greg> "or that the browser doesn't accessibly render content *even thought it is* authored in compliance with WCAG"
JS: Suggest, it is recommended but not required that user agent vendors provide staff to respond to such feedback.
<jeanne> Note: It is recommended, but not required, that the user agent vendor assign staff to review and respond to these comments in a timely manner so that problems can be resolved and overall accessibility can be improved.
GL: What we really mean is that they can iniate the feedback process from within the user agent
MH: Would mechanism be a better word than facility
GL: I don't see a
differencwe
... Sidetrack...I wanted to change the middle a bit....
<Greg> I think we need to change the phrase "faults in accessibility support within the user agent", which reads like a single clause, but is really halves of two separate clauses.
<Greg> The user isn't reporting "faults in accessibility support within the user agent", but "is reporting accessibility faults" using facilities available within the user agent or some such.
<Greg> The wording is ambiguous.
<Greg> Reporting "faults in the user agent's accessibility support".
What about "The user agent provides a mechanism for users to report user agent accessibility issues"
<Greg> "Within the user agent, the user can initiate the process of reporting faults in the user agent's accessibility support."
JS: AA?
KF: No
<jeanne> A is minimum that everyone is capable of doing.
<jeanne> AA is more than the minimum, but still very important for groups of people with disabilities
SH: Is is very important!
JR: Agree but problem is timing...has no bearing on the usability at the time of use
JS: Could backfire due to small population
KF: I think its important but its not a real-time thing.
MH: Key thing is report, not reporting and receiving fixes.
JR: I think email in the help is fine.
MH: I'd prefer something more, but its ok.
GL: What about a web-based version?
JR: Yes
KF: Agree
SH: Concerned that a web-based support system will actually just hide the contact info
<jeanne> +1 to Kelly's. Keep it open, and more people will implement it.
KF: Agree with concern, but it is the best chance for implementation
SH: I think we can leave it open, if the mechanims is a link to website from menu item, then ok
GL: All seems reasonable but if nothing in the user agent UI, is that ok?
MH: Both JR and GL versions say user agent provides, not that the vendor provides.
GL: Ok so in intent we can explain that iniation happens in the user agent UI
JR: Agree with that
SH: Kudos to Jaime Rice.
GL: +1
<mhakkinen> +1
<sharper> +1
KF: In survey also change to example
<jeanne> Alice is a visually impaired college student who frequently uses a refreshable braille display with her Web browser. Occasionally she experiences difficulty with Web content containing elements such as drop-down list boxes or complex menus, where the text is only partially rendered on the braille display. Alice notices this incompatibility and navigates to the feedback section of her browser. After
<jeanne> providing some basic information (such as AT software and computer hardware used), Alice is able to describe the problem she encountered and submit the report to the browser vendor.
<jeanne> +1 to Jan.
<jeanne> A contact link on a website is not sufficient to satisfy this success criterion.
<sharper> +1 to Jan
Resolved: The user agent provides a mechanism for users to report user agent accessibility issues
Resolved: Add to intent that the mechanism must be iniated in the user agent UI
KF: Back to 4.1.1...
The user agent provides a mechanism for users to report user agent accessibility issues
https://www.w3.org/2002/09/wbs/36791/20120710/results#xq3
GL: Could simplify...
<Greg> "Non-web-based user agent user interfaces support platform accessibility services."
<Greg> "Support platform accessibility services" would seem to imply fully support the range of functions, unlike "communicate with" or "expose information using".
<Greg> Could even say "fully support" but that could be problematic, especially if things are optional.
<Greg> Discussion of whether the UA has to support 100%, or 5%, or the platform accessibility services in ofder to comply.
JR: I'm ok with "support"
<Greg> Another phrasing to avoid the huge noun stack might be something like "Portions of the user agent user interface that are not web-based..."
<Greg> Or "Non-web based portions of the user agent user interface..."
<Greg> Either would be better than ""Non-web-based user agent user interfaces".
<Greg> "Non-web based portions of the user agent user interface support platform accessibility services."?
<Greg> We also need to clarify in the IER that this does not prohibit web-based portions of the user agent user interface from also supporting platform accessibility services.
Relevant platform accessibility services are supported.
GL: We should explain why it applies to only non-web-based things
<Greg> ...in the Intent.
GL: "Relevant platform accessibility services are supported." seems ok
<kford> rrsagenrrsagent, make minutes
Current: "4.1.1 Platform Accessibility Architecture: The user agent supports a platform accessibility architecture relevant to the operating environment. "
Working version "Relevant platform accessibility services are supported."
<Greg> We should definitely keep the more specific list of Related Resources from the current draft, minus PDF Accessibility API (which is for ATVs).
<Greg> Jan's version is passive voice, but I like the plural instead of singular.
<Greg> "4.1.1 Platform Accessibility Services: The user agent supports relevant platform accessibility services."
<Greg> That gets the plural and shortens it, both per Jan's suggestion.
JR: OK
<Greg> But keeps active voice for style consistency with other SC.
KF: Fine
GL: Intent needs to combine best parts of both
JS: Do you have time to do that?
KF: Let's call it a day
<Greg> I'll try.
oops
<jeanne> ACTION: jeanne to add the links to 4.1.1 Related Resources from Jan's proposal. [recorded in http://www.w3.org/2012/07/12-ua-minutes.html#action01]
<trackbot> Created ACTION-741 - Add the links to 4.1.1 Related Resources from Jan's proposal. [on Jeanne F Spellman - due 2012-07-19].
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/or/of/ Found Scribe: Jan Inferring ScribeNick: Jan Default Present: [Microsoft], Jeanne, Mark, Jan, Greg_Lowney, sharper Present: [Microsoft] Jeanne Mark Jan Greg_Lowney sharper Regrets: Jim Found Date: 12 Jul 2012 Guessing minutes URL: http://www.w3.org/2012/07/12-ua-minutes.html People with action items: jeanne[End of scribe.perl diagnostic output]