See also: IRC log
<KFord> but actually if there should be even this brief content that's not there, just kind of boilplate text.
<KFord> Love all the different permission issues with technology.
<jeanne> http://www.w3.org/WAI/UA/scribing.html
<Alan> testing...
<scribe> Scribe: Jan
JA: Simon did send
JB: I had action to reply but
haven't yet
... First thanks for them
... One thought...Jim reminded us when he got back that 4.1.1
to 4.1.12 are actually success criteria
... In other docs we havne't put rationales for this lvel...in
other docs this went in "understanding" docs
... But at moment that's noit on our committed deliverables
list
... Another concern is that while this is really good starter
text but would need more peoples' time to polish
... So we are kind of reluctant to take on this additional
work...
... Also you suggested litterature references....
... Just a couple of concerns...1. external link persistence is
an issue from a technical report (TR)....
... also an ISO JTC group I was on tried this a few years back
and had trouble with it
... Am I clear?
SH: Only thing I thought - sent
an Email - with re: rationale: I'm happy to go along with
it...but I worry that we will be asking developers to do things
and tonot have rationale might hinder take up of rules
... But I understand time constraints
... Benefits as well
JB: We did agree with that...esp.
wrt UAAG1 not getting as much uptake
... Concern was actually that rationales might not be
consistent. Some are benefit, some are barrier....our
experience in other groups is almost to wqrite these by
formula
... And with regard to links, it should be as concise as
possible
... Anyhow there was pretty stong support in last mtg of having
these avaiable but there was just concern about scope.
... Also reminder that group needs to publish on heartbeat
schedule
SH: I'm fine to go along
JB: Other people ok?
... We could revisit it later?
... We do specifically want to save the text for later use
JA: Agree that saving text is a great idea
<scribe> ACTION: JS to Save the potential rationales written by SH [recorded in http://www.w3.org/2008/07/17-ua-minutes.html#action01]
<jeanne> ACTION: JS will set up tracking system for UAWG [recorded in http://www.w3.org/2008/07/17-ua-minutes.html#action02]
:)
AC: We should think about best formula for writing these
JB: Maybe we can select several different guidelines and then try the various formats...barriers, benefits, etc.
<jeanne> ACTION:JS will set up tracking system for UAWG [recorded in http://www.w3.org/2008/07/17-ua-minutes.html#action03]
JB: I might lean towards
"barrier-reduction" rather than "make it nice"
... Bunch of considerations
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0036.html
JA: We want to keep 4.1.1
unchanged, remove 4.1.7 and reword 4.1.6
... Decide now?
JB: OK if will be short discussion?
KF: "Processed content" defined?
JR: Ties into whole chrome/content display discussion
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0018.html
JA: will come back to this
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0024.html
<jeanne> JR: Action item on precedence of keyboard processing. JR thinks we can simplify by having one SC (we previously had 2)
<jeanne> ... that states the preferred order.
JA: Let's flag for follow-up
KF: I have some concerns
JS: Yes I did
<jeanne> http://www.w3.org/WAI/UA/2008/keyboardProposals20080714.html
JS: Will take some discussion as well
JA: Then...
... Would like to hold off on discussing"Schedule for
publication of next draft."
... Let's take up 4.1.1, 4.1.6, and 4.1.7
<AllanJ> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0036.html
<AllanJ> www.w3.org/tr/uaag2
http://www.w3.org/WAI/UA/2008/keyboardProposals20080714.html
JB: Reads: 4.1.1 Keyboard
Operation: All functionality can be operated via the keyboard
using sequential and/or direct keyboard commands that do not
require specific timings for individual keystrokes, except
where the underlying function requires input that depends on
the path of the user's movement and not just the endpoints
(e.g., free hand drawing). This does not forbid and should
not...
... discourage providing mouse input or other input methods in
addition to keyboard operation.
JA: So as part of the review I did with JR, we decided this is ok
JB: THink "provisionally OK"
should be a category
... Provisionally yes
KF: Provisionally yes
JA: OK
JR, SH, JS: Provisionally yes
AC: COuld we simplify?
JB: I agree
KF: I think we drill to far down quickly....I can see lots of places where simplification needed
JB: Good point
AC: OK
JA: OK we can wordsmith after 4.1
JB: Next is to remove: 4.1.6 Standard Text Area Conventions: Views that render text support the standard text area conventions for the platform including, but not necessarily limited to: character keys, backspace/delete, insert, "arrow" key navigation (e.g., "caret" browsing), page up/page down, navigate to start/end, navigate by paragraph, shift-to-select mechanism, etc.
OOPS
JA: Something different
... Clarifies that we want to remove 4.1.7 and rewording
4.1.6
KF: So sentence in 4.1.1 pretty
abstract...
... So supplemental info...
... I would try to move stuff in 4.1.7 up into 4.1.1
AC: Can't agree
... This is actually touching on something
interesting....conventions
... Reversability important
KF: Should merge first then word smith down
http://www.w3.org/TR/UAAG20/#principle-follow-specs
<AllanJ> JR: there is another guideline 1.1, observe operating environment conventions
<AllanJ> ... platform, mobile phone, etc.
KF: 4.1.1 needs a semblance of an example
JB: Gets back into SH's need for
rationales
... I actually think this may be the worst section of the
doc
... In terms of trying to sort things out
... I've never seen a really good capture of keyboard
... May be that we need rationles for this section
KF: 4.1.1 says all functionality
can be operated from keyboard...
... 4.1.7 is what really means by all
AC: It's a clarification...a positive example to go with negative one....
The user can, through keyboard input alone, navigate to and operate all of the functions included in the user interface (e.g., navigating and selecting content within views, operating the user interface "chrome", installing and configuring the user agent, and accessing documentation), except where the underlying function requires input that depends on the path of the user's movement and not...
scribe: just the endpoints (e.g. freeform drawing).
@@(e.g., navigating and selecting content within views, operating the user interface "chrome", installing and configuring the user agent, and accessing documentation)@@
All functionality can be operated via the keyboard @@(e.g., navigating and selecting content within views, operating the user interface "chrome", installing and configuring the user agent, and accessing documentation)@@
using sequential and/or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g., free hand drawing). This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
JB: Don't like Chrome
JR: Can say controls or something
<Judy> judy: not simply that i don't like it; i note that we're not using it consistently nor correctly and it seems to add to the jargon barrier not only for non-developer audiences but even for some developer audiences.
JR: As an aside we have reworded 4.1.1 a lot...very terse....and almost back where we started
that was JA
JA: We're spinning wheels
KF: But sometimes this is healthy because helps find comfort level
JA: Other conflict is how terse
to make things
... Worry about being too prescriptive then too terse
JB: Well I'm having a concern
that last time we didn't even get to the end of 4.1.12.\
... So agenda....we've gone through and are now returning
JA: I wan't here last week, not sure what we got through
JB: I do not believe we made it through with detailed discussion
JS: How much change to 4.1.11 and 4.1.12? JS?
that was JB
JS: No change by me except small grammar fix
JA: So we were thrashing on 4.1.1...
<scribe> ACTION: KF to Look at how 4.1.1 and 4.1.7 might fit together [recorded in http://www.w3.org/2008/07/17-ua-minutes.html#action04]
<KFord> Note to kfored, look at older wording from log here.
JA: Next part is rewording of
4.1.6
... 4.1.6 was about standard text conventions
... Our proposed wording is: 4.1.6 Caret Navigation: The user
can use the keyboard to navigate to and
select characters in any text in the processed content.
KF: 2 peices of general
feedback...this would only be of viewport to be more
clear
... And defining "processed content"
<AllanJ> JR: this is exactly the reason we need the separation between chrome and content.
JR: THis is exactly why we need chrome/content display split
<AllanJ> JR. The user can use the keyboard to navigate to and
<AllanJ> select characters any text in the xxx (viewport, content display, processed content,
<AllanJ> etc.)
JB: Would this split 4.1?
JR: No we just need to be clear
JS: Big issue...leaning towards dividing adifferent way...into who's responsible for developing it
KF: Maybe I"m just showing my
bias....browser is at least two things "chrome" and other is
"web content"....and I want our document it reflect that
... So want all UA's to implement caret browsing?
JA: Right
JB: How is this different than 4.1.1?
JA: Applies to user interface
JB: I think split only applies to
some checkpoints
... If 4.1.1 and 4.1.6 are parallel,,,maybe we need to make
that very clear
... So they can't be mistaken for smae thing
Maybe 4.1.6 needs to come up to the top
AC: Hard to imagine not drawing
really clear distinction between user interface and
content...some SC's can be collapsed togther...
... But I think we should actually repeat wording in UI vs.
content display
JS: But as more apps come on line we are backing ourself into corner with this distniction
<AllanJ> JR: I don't agree.
<AllanJ> ... Al G. made a comment. on 7/11 about this issue
<AllanJ> ... imagine, viewer with video running using a webbased external viewer SMIL, etc.
<AllanJ> ... there are things that are different from developer content (player) and author content (actual movie with caption)
<AllanJ> ... the player has a different set of criteria (keyboard accessibility, accessible help)
<AllanJ> ... the movie must follow WCAG.
<AllanJ> ... can't tell from the tags, could all be html, even in the chrome could be html
KF: Call it what you will...but
caret browsing is going to apply to web content...
... Kind of do that with processed content
... In web page if I write "File" I want to select that, but
dowbt need to select "File" in menu
... Very different from UI
... Explicit aims trying to acheive need to be clear
JA: As necessary...
... Thinking back to comment earlier, Flash in web page, does
user agent need to provide caret browsing...
... Gives examples of embedded user agents
KF: I don't disagree..we need to very explicit
JB: Process comment....feel like
I'm getting picture of why we are going in circles....
... We don't have well developed understanding of the
need.
... Trying to discuss on level of wording...without shared
understanding
... People need to the group can be left out when shared
understanding is not explicit
... Maybe between now and next week, several people can attempt
to write rationales
... Reaction?
<AllanJ> JR: will be part of group
JR: I would join that group.
JA: Me too
SH: As a newbie everything seems
to come back to 4.1.1 which is very comprhensive
... Also 4.1.5, 4.6., 4.1.7, .11 and .12 are subclasses of
4.1.1
JB: Interesting
observations
... THis was a very tough part of TEITAC as well
... I'm still not satisfied with what we have
... Maybe 4 or 5 essential things...
... So we are almost out of time
JS: Would like to join
JA: Somewhere along the way principles have been lost
KF: I'd be willing to help too
<scribe> ACTION: JR, JA, JS, KF: Write rationales for all of the checkpoints. [recorded in http://www.w3.org/2008/07/17-ua-minutes.html#action05]
KF: Have to go
JA: Next week we'll do the next draft schedule first
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Jan Inferring ScribeNick: Jan Default Present: Jim_Allan, Jan, Jeanne, Simon, Mark_Hakkinen, Judy, Kelly_Ford, Alan_Cantor Present: Jim_Allan Jan Jeanne Simon Mark_Hakkinen Judy Kelly_Ford Alan_Cantor Regrets: Gregory_Rosmaita Got date from IRC log name: 17 Jul 2008 Guessing minutes URL: http://www.w3.org/2008/07/17-ua-minutes.html People with action items: jr js kf WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]