IRC log of ua on 2005-03-03

Timestamps are in UTC.

14:04:09 [RRSAgent]
RRSAgent has joined #ua
14:04:09 [RRSAgent]
logging to http://www.w3.org/2005/03/03-ua-irc
14:04:27 [jim]
jim has joined #ua
14:04:29 [mcmay]
rrsagent, make log world
14:04:41 [kyle]
kyle has joined #ua
14:05:08 [JRG]
JRG has joined #UA
14:05:58 [jim]
introductions
14:09:09 [louie]
louie has joined #ua
14:10:35 [jim]
discussing Mozilla keyboard model from Sun Beijing
14:11:15 [jim]
overview of the UAAG meeting today
14:11:53 [jim]
development of test suites for xhtml, joint meeting with xhtml wg in afternoon
14:14:40 [korn]
korn has joined #ua
14:16:31 [jim]
UA test suites-have been working on tests for 3 years. history of UAAG, and process of developing UAAG
14:18:30 [jim]
jrg demos uaag test suites system
14:24:42 [jim]
http://cita.rehab.uiuc.edu/wai-eval/index.php?option=Test%20Suites
14:30:23 [jim]
contact jrg for login/password to enter system for conducting test jongund@uiuc.edu
14:32:35 [korn]
testging...
14:32:54 [jim]
jim has joined #ua
14:33:01 [JRG]
JRG has joined #UA
14:33:16 [cklaws]
cklaws has joined #ua
14:33:20 [kyle]
kyle has joined #ua
14:34:21 [jim]
Jessie (Sun) demos mozilla accessibility
14:36:22 [jim]
speech access on sun desktop with mozilla
14:39:05 [aaronlev]
aaronlev has joined #ua
14:40:53 [jim]
there is a describe feature, but need more "help" for blind users. submit feedback to bugzilla.gnome.org file against screenreader or mozilla at bugzilla.mozilla.org
14:41:19 [korn]
File Gnopernicus bugs: http://bugzilla.gnome.org category 'gnopernicus'
14:41:30 [korn]
File Mozilla accessibility bugs: http://bugzilla.mozilla.org
14:41:59 [korn]
Can discuss Gnopernicus (and general GNOME) accessibility bugs: gnome-accessibility-list@gnome.org
14:42:04 [jim]
screen reader making xul accessible
14:42:30 [jim]
xul accessibility guidelines
14:43:17 [aaronlev]
http://www.mozilla.org/access/xul-guidelines
14:44:49 [jim]
f7 caret browsing mode, arrow keys control audio rendering (character, word, line)
14:45:57 [jim]
word navigation caret position is different from character navigation caret position.
14:47:02 [jim]
can change caret postion behavior in user profile (about:config)
14:48:50 [jim]
mozilla prefers looking at system settings to establish browser behaviors
14:52:18 [jim]
showing mozilla with speech in uaag test suites.
14:53:12 [jim]
label on input controls, if there is no label on form control will screen reader ignore it or guess. preference is to ignore.
14:54:07 [jim]
hpr looks for "for" attribute, then "label" element, then proximity algorithm
14:55:56 [jim]
korn: first release, follow the rules and only the rules, line in sand for developers, push good behavior, then come back and let assistive tech fill in the gaps
14:57:00 [jim]
jg: if author puts in appropriate code then the user agent should use it. and use heuristics only if proper code is missing
14:58:19 [jim]
alt ] to exit form control
15:00:36 [jim]
move in to radio button, presented redundant information - spoke "value" and on screen label text - blue blue
15:07:33 [mimasa]
mimasa has joined #ua
15:07:54 [jim]
change value=1, still said blue blue, discussion ensued, different browser behavior and assistive technology behavior
15:12:36 [jim]
optgroup-discussion about speaking group label, when or if it should occur
15:13:54 [JRG]
http://cita.rehab.uiuc.edu/mozilla/ts-test-page-input.html
15:15:59 [jim]
discussion of fieldset/legend rendering and screen reader use
15:19:02 [jim]
of them with radio buttons and checkboxes
15:19:51 [jim]
discussion of disabled form controls, should not be able to tab to disabled controls. should be able to tab to read-only controls and read them
15:24:42 [JRG]
http://cita.rehab.uiuc.edu/mozilla/ts-index.html
15:29:32 [jim]
data table test http://cita.rehab.uiuc.edu/mozilla/ts-test-page-text.html#data
15:31:15 [jim]
discussion of character reading mode between table cells, should it say new table cell or just continue reading the next character regardless of cell boundries
15:32:45 [JRG]
http://cita.rehab.uiuc.edu/mozilla/ts-test-page-input.html
15:39:36 [jim]
discussion of definition of "container"
15:40:09 [jim]
iframe test.
15:42:50 [jim]
gnopernicus uses platform specific api and role, doesn't currently have a
15:43:04 [jim]
break until 11am
15:44:14 [jim]
gnopernicus doesn'tcurrently have a role for iframe, discussion of xhtml existence of frame, xlink, embedding
16:05:48 [jim]
accessible xul authoring guidelines http://www.mozilla.org/access/xul-guidelines presentation
16:06:43 [jim]
by aaron leventhal
16:06:57 [jim]
extension writers should follow these
16:08:44 [jim]
2. no keyboard access to the toolbar in mozilla, toolbar items should be in the menus
16:10:01 [jim]
3. define sensible focus behavior - change order of 2 and 3 to make focus items occur in tandem
16:11:24 [Zakim]
Zakim has left #ua
16:14:31 [jim]
4. problem with multiply defined access keys, do they cycle through. mozilla developer toolbar key controls override other extension toolbar keys
16:20:42 [jim]
** need for review of xul access key faq http://www.mozilla.org/access/keyboard/accesskey for linux
16:21:40 [jim]
mozilla trying to merge windows, linux, mac hci guidelines
16:22:44 [jessie]
jessie has joined #ua
16:24:02 [jim]
8. make it stronger. "don't use mouse only controls" if you only have mouse only controls you are not accessible.
16:25:05 [jim]
in sun, you can attach actions to events (?), do a mouse over and substitute key press or other appropriate action
16:26:58 [jim]
suggest putting in context menu
16:28:46 [jim]
can't scroll from keyboard in xul
16:33:24 [jim]
need functionality to change the column width from the keyboard
16:39:04 [jim]
themes - need to respect color and font size on the desktop - from 508 1194.21 - should inherit
16:40:21 [jim]
link to -moz- mozilla proprietary theme definition
16:41:57 [jim]
ask developers to test, perhaps develop xul accessibility test suite. e.g. change to large fonts on the desktop, does the xul widget change fonts
16:42:51 [jim]
xul discussion ends
16:42:57 [JRG]
http://www.disability.uiuc.edu/ita/dwatt/accessext/accessibilityext.xpi
16:43:51 [jim]
discussion of accessibility extension for mozilla from uiuc
16:52:50 [jim]
navigation dialog - should have "move to" as well as activate link, allows user to read information around the anchor to get the context of the link
16:56:02 [jim]
not picking up alt text of images, blogs.sun.com/korn
16:58:34 [jim]
was an error in the page not with the tool.
16:59:27 [aaronlev]
How to restyle focus outline using CSS: https://bugzilla.mozilla.org/attachment.cgi?id=165562
17:04:32 [jim]
we will move the wall at 3:30 you are next door
17:05:38 [jim]
break for lunch, eat in room, discuss xhtml issues in prep for meeting
17:47:29 [aaronlev]
aaronlev has joined #ua
17:48:32 [jim]
alt popup extension for mozilla http://piro.sakura.ne.jp/xul/_popupalt.html.en
17:54:53 [cklaws]
cklaws has joined #ua
18:04:07 [jim]
uaag svg joint meeting
18:04:49 [jim]
Craig Northway from SVG (canoon)
18:04:59 [jim]
introductions
18:06:19 [jim]
review uaag svg accessibility document
18:06:46 [jim]
svg group has a draft response, not yet ready to deliver to uaag
18:07:17 [jim]
want to learn about plans for svg test suites.
18:07:58 [jim]
uaag charter task the group with developing svg test suites, want to coordinate with svg group test suites
18:08:08 [kyle]
kyle has joined #ua
18:08:14 [jim]
want to have svg accessibility in the useragent
18:09:48 [jim]
personal comment (Craig) - document is push for things beyond the svg spec, they are more user agent items, and are something that is better placed in the conformance document
18:10:58 [jim]
jg: want implementation to include accessibility, using style to change the content
18:11:21 [jim]
e.g. gray scale,
18:11:56 [jim]
needs of people with disabiities seems to lead the development of new features that all users can benefit from.
18:13:45 [jim]
seems to be a year or two lag in the implementation of accessibility features. user agents may include different accessibility features, which is the author or assistive technology supposed to pay attention to?
18:14:59 [jim]
jg: gives accessibility scenarios.
18:15:32 [jim]
specs need to provide an expected set of behaviors for the rendering of the items.
18:15:39 [jim]
Craig:
18:16:53 [jim]
color changes - they are useful, user may want to change the color of the svg. this does not fit with the rendering model, can't use a compositing operator,
18:17:23 [jim]
do you want to change the way individual items blend together or change the whole image
18:18:10 [jim]
korn: AT users want to use one tool across the platform
18:18:40 [jim]
compositing is beginning to happen on the desktop, want to have more control over the rendering.
18:19:47 [jim]
craig: color items are more related to the filtering effects in svg
18:20:30 [jim]
jg: comp-op property
18:21:01 [jim]
craig: better to do with filter effect (my opinion)
18:21:40 [jim]
working group thought it was a post rendering issue, add requirements to the accessiblity appendix,
18:22:30 [jim]
svg 1.2 is being redone at the moment to a full version.
18:22:53 [jim]
any new drafts will have an accessibility chapter.
18:23:48 [jim]
korn: svg to make an engine diagram, it is broken into parts, exhaust, fan,
18:24:24 [jim]
with a compositing manager, could gray out everything but exhaust
18:24:39 [jim]
craig: could also do it with filters.
18:25:52 [jim]
jg: with the current immplementation, author would have to script the make the section gray work now
18:27:13 [jim]
craig: this is a large expansion of the color statement in the document.
18:27:29 [jim]
you want visual access to the dom and interact with them
18:28:07 [jim]
korn: currently can have personal custom style sheet, UA allows this to happen
18:28:41 [jim]
craig: can use css to style, current svg views don't allow personal style sheets
18:30:10 [jim]
korn: need to have the svg guidelines make authoring suggestions,
18:30:53 [jim]
what are the grouping categories?
18:31:15 [jim]
craig: enumerates them
18:31:30 [jim]
korn: any relationships other than grouping
18:31:53 [jim]
craig: css selector relationships (parent, child, etc.)
18:32:28 [jim]
korn: call out relationship,
18:33:12 [jim]
craig: things can have description, title, etc. with the element, but not an id distant reference
18:34:37 [jim]
ah, like a label for the item, like a tooltip, or you could group the text and the item
18:35:32 [jim]
korn: want a group operator and label operator so you can extract the text
18:35:48 [jim]
craig: could genericize it.
18:37:36 [jim]
korn: title and desc are not rendered on the display. if already have a callout, make a tooltip for an item it becomes the accessible description of the time, using the label/for then can programmatically link the description and item.
18:38:49 [jim]
craig: hint element, if tooltip enabled then the hint will be used for the tooltip, but must be a child of a graphical element. hint is a string
18:39:18 [jim]
korn: ideally hint would be an element that can form a relationship with other elements.
18:39:57 [jim]
jg: ***action send relationship concept to svg (new document)
18:40:25 [jim]
color issues can be resolved with filter options.
18:41:08 [jim]
craig: would be part of the accessibility chapter not part of the spec
18:41:35 [jim]
jg: need to continue the dialog
18:41:56 [jim]
craig: would be a recommendation not required in the spec
18:42:29 [jim]
--include accessibilty features as part of svg examples
18:42:51 [jim]
craig: accessibility examples are in a seperate section
18:43:26 [jim]
korn: makes sense, but all other examples exemplars of accessibility.
18:43:51 [jim]
then have a special section extending the accessibility.
18:44:23 [jim]
craig: test suites, need help writing the examples, we can do svg, don't know the accessibility part,
18:44:57 [korn]
korn has joined #ua
18:45:05 [jim]
jg: would love to work with you, connect us with the test suite contact
18:45:08 [korn]
test.
18:56:07 [jim]
author has to provide some information about an image, that explains the images and the relationships between items
18:58:50 [jim]
svg tiny, small subset of svg-full for mobile devices, contains most useful features.
19:00:06 [jim]
may be more implementation on the desktop as a result of svg-tiny, development is less costly
19:00:22 [jim]
--outline view of the document
19:00:45 [jim]
craig: use xslt to transform to html
19:01:10 [jim]
aaron: assumes static content.
19:01:42 [jim]
korn: getting all of the rendered information out of the svg objects...bounding rectangles
19:02:33 [jim]
craig: bounding comes from the dom. svg extended the dom, in the svg spec.get bounding box, tranformation matrix,
19:02:52 [jim]
user agent will know this from the dom.
19:03:12 [jim]
screen magnifiers will find this useful.
19:04:12 [jim]
craig: will be addressing text only view in the accessibility chapter,
19:05:31 [jim]
jg: a spec has to have features that all users can benefit from. (cynically)
19:06:00 [jim]
korn: try to have things in teh spec that are multi use.
19:06:58 [jim]
jg: have structure, so the user can style the information to meet their needs. the author can see this and create new ways to present information
19:07:43 [jim]
craig: have to do things structurally if you have animated scripted content.
19:08:34 [jim]
slatin: multimodal demos yesterday, showed uses for other folks than just those with disabilities, electronic curb cuts
19:09:16 [jim]
--all items in dom have a focusable property
19:10:01 [cklaws]
cklaws has joined #ua
19:10:17 [jim]
can focus on container elements
19:11:01 [jim]
what about button with drop shadow, can you focus on the drop shadow
19:11:14 [jim]
depends how it was created
19:11:34 [jim]
craig: need to look a nested focus
19:12:17 [jim]
author decides what is focusable
19:13:03 [jim]
aaron: focusablity is not boolean, should be part of main tabbing order,
19:14:51 [jim]
craig: focusable - mean item can get focus, but not how to navigate to it. can use navnext and navprev to move focus, author must provide all of the hooks
19:15:28 [jim]
nav-up,down, left, right. (not in/out)
19:23:09 [jim]
---mozilla keyboard proposal
19:24:47 [jim]
www.mozilla.org/access/keyboard
19:26:53 [JRG]
http://www.mozilla.org/access/keyboard/proposal
19:27:40 [jim]
review document
19:30:25 [jim]
frame boundries and caret movement, caret stops
19:31:22 [jim]
frames is different dom.
19:32:41 [jim]
aaron: from the user view, a frame is just a container on the screen, the user doesn't care what it is, just want to select into it.
19:33:20 [jim]
**no stong opinion of the group about frame boundries
19:34:27 [jim]
ctrl+right - different behaviors depending on OS
19:34:38 [jim]
mozilla should follow the desktop
19:36:53 [jim]
--discontinous navigation
19:39:23 [jim]
ok
19:40:25 [jim]
--text selection
19:43:16 [jim]
--keyboard across frame boundry
19:46:03 [jim]
tab and f6 should include both frameset and iframe - move across frame boundry
19:46:58 [jim]
--form control navigation
19:49:08 [jim]
jg: when you move caret into form control, have status line update to include form label, author will see some benefit.
19:51:29 [jim]
korn: suggest haveing about:config setting to turn this off. screen readers check status line for changes and reads it out
19:54:48 [jim]
aaron: use alt+] to move to next form control, (or some other character)
19:55:54 [jim]
discussion of using alt] to move in and out of form control moving down the page and alt[ moving in and out of form controls up the page.
19:56:38 [jim]
perhaps have additional navigation schemes.
19:57:19 [jim]
look at this function more closely
19:59:00 [jim]
jim has left #ua
19:59:18 [JRG]
Keyboard bindings for get out of a form control
19:59:53 [JRG]
Aaron: Use alt+shift+arrow for movng instead of control+[
19:59:59 [JRG]
Internationalization issues
20:00:21 [JRG]
Alt+shift is avalaible on most keyboard
20:00:44 [JRG]
Kyle: Is arrow the right key
20:01:21 [JRG]
PK: How do you tell if you are in edit mode?
20:01:38 [JRG]
PK: GP will tell you that you are in edit mode
20:02:17 [JRG]
PK: GP will tell you when you leave something
20:02:31 [JRG]
AL: Arrows are useful for table navgation
20:03:01 [JRG]
AL: Atl+shift+arrow may be used for directional navigation, may get back into the trunk
20:03:14 [JRG]
PK: There is not a consensus
20:03:31 [JRG]
AL: There doesn't seem to be agreement
20:03:44 [JRG]
Kyle: What is the conclusion
20:03:53 [JRG]
AL: There is no conclusion
20:03:55 [Steven]
Steven has joined #ua
20:04:04 [Steven]
Steven has left #ua
20:04:26 [aaronlev]
http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_13228
20:42:21 [shinichi]
shinichi has joined #ua
20:43:22 [mcmay]
mcmay has joined #ua
20:44:05 [RichS]
RichS has joined #ua
20:44:18 [mcmay]
jg: Comments on 24 Feb draft of XHTML 2
20:44:24 [aaronlev]
aaronlev has joined #ua
20:44:44 [Steven]
Steven has joined #ua
20:45:13 [mcmay]
jg: We talk about enabled elements, maps to focusable.
20:45:29 [mdubinko]
mdubinko has joined #ua
20:45:58 [mcmay]
sp: I have an issue with "visible" here.
20:46:14 [mcmay]
jg: cite attrib in quote element. Is that focusable?
20:46:34 [mcmay]
sp: not at the moment. cite is metadata. may well be navigable, but only to the extent that all metadata is navigable.
20:46:45 [mcmay]
sp: Link elements are not focusable in this definition.
20:46:57 [mcmay]
jg: elements with event handlers?
20:47:23 [mcmay]
sp: not necessarily interactive (load, submitdone in XForms). XForms is full of non-interaction events.
20:47:32 [mcmay]
jg: a paragraph with an onfocus/onblur event?
20:47:55 [mcmay]
sp: by putting a listener on an event, doesn't mean that element is ever going to get that event.
20:48:29 [mcmay]
Mark Birbeck (mb): If you stick a listener on a p, doesn't mean the p originates the event.
20:49:11 [mcmay]
al: Could put focus on buttons contained within.
20:49:24 [mcmay]
jg: we hav a checkpoint to activate event handlers.
20:49:40 [mcmay]
cl: ...using the keyboard
20:50:05 [mcmay]
jg: on an onmouseover event, UA should also supply a way to handle via keyboard.
20:50:56 [mcmay]
sp: these are requirements on the user agent and not the language.
20:51:03 [mcmay]
jg: what do you define focusable as?
20:52:00 [mcmay]
mb: need to specify the type of events. DOM UIEvent should be a part of this.
20:52:21 [mcmay]
rs: Just because you don't have it focusable doesn't mean you don't want it in the tabindex.
20:52:50 [mcmay]
sp: currently defined as all elements that can receive a DOMActivate. Can't DOMActivate a p.
20:53:22 [mcmay]
rs: Other side of this: someone wants to put a handler on a div/span.
20:53:43 [mcmay]
rs: This looks like anchors/form elements only.
20:53:54 [mcmay]
rs: Example: custom widget bound to the model using div/span.
20:54:05 [mcmay]
sp: that could get a DOMActivate apart from these?
20:54:07 [mcmay]
rs: yes.
20:54:20 [mcmay]
mb: Fall under the category of something with an event listener?
20:54:25 [mcmay]
rs: Could we bind a listener?
20:55:08 [mcmay]
sp: XML Events does the binding. Want to be more generic than XHTML 2. Want to say that any element can create a handler.
20:55:45 [mcmay]
sp: Don't want to make a submission element focusable.
20:56:13 [Steven]
9FOR EXAMPLE0
20:56:22 [Steven]
(for example)
20:57:07 [mcmay]
sp: roles are far more generic, but you could say elements that are targeted by the access element, that makes those focusable.
20:57:26 [mcmay]
cl: How to expose roles?
20:57:31 [mcmay]
sp: targetrole
20:58:10 [mcmay]
sp: If you have 16 bound to same key, will scroll between them.
20:58:25 [mcmay]
al: If there are a lot of descendent elements, will put a handler on a parent element.
20:58:30 [mcmay]
sp: Not all events bubble.
20:58:32 [mcmay]
al: Focus does.
20:58:39 [mcmay]
sp: XForms focus doesn't bubble.
21:00:30 [mcmay]
jg: We have a requirement to let people choose their own style, and UAs must or should conform to UAAG 1.0.
21:00:41 [mcmay]
sp: If we say UAAG, other points are subsumed?
21:00:44 [mcmay]
jg: Yes.
21:02:39 [mcmay]
sp: to conform to UAAG 1.0, would have to select a conformance level, and so wouldn't need to specify single-A.
21:02:54 [mcmay]
jg: Could say must conform to A, should conform to AA, may conform to AAA.
21:05:33 [mcmay]
mm: UAAG contains checkpoints that involve repair, because of legacy. Could remove those from conformance for something like XHTML 2.
21:05:48 [mcmay]
sp: Many of our UAs are plugins. How does that affect it?
21:07:01 [mcmay]
mb: Wouldn't think it would be a problem.
21:07:19 [mcmay]
sp: test cases?
21:07:26 [mcmay]
jg: We'd like to work with you on that.
21:08:37 [mcmay]
jg: We have an eval system for UAAG. Users can look at our requirements.
21:09:02 [mimasa]
(FYI, we have some example documents at: http://www.w3.org/2000/07/8378/xhtml2/spec-examples/ )
21:09:11 [mcmay]
jg: If we can build a system that creates the proper markup, we can build it.
21:09:19 [Steven]
rrsagent, pointer?
21:09:19 [RRSAgent]
See http://www.w3.org/2005/03/03-ua-irc#T21-09-19
21:09:47 [jessie]
jessie has joined #ua
21:09:54 [mcmay]
jg: We can generate our own reports out of this.
21:11:20 [mcmay]
sp: suppose we have a kiosk. Then can have no XHTML 2 impl.
21:11:55 [mcmay]
jg: Kiosks can have a keyboard or alt UI working via accessibility APIs.
21:12:12 [mcmay]
pk: Also onscreen keyboard.
21:12:18 [mcmay]
sp: Do those count for keyboard compliance?
21:12:20 [mcmay]
mm: Yes.
21:14:51 [mcmay]
jg: Most UAs don't support nav to headers. Opera, ATs. Hard for authors to know that they did the right thing.
21:15:07 [mcmay]
jg: Should be some language that UAs are expected to do something with header other than style it. Navigation to headers.
21:16:01 [mcmay]
sp: Does UAAG say that?
21:16:51 [mcmay]
jg: We require users to move focus forward and reverse, then to be able to navigate structure (P2).
21:18:03 [mcmay]
pk: Under 1194.25 of Section 508, kiosks must be directly accessible without users having to add AT. Also 1194.21(a), for keyboard access.
21:18:16 [mcmay]
pk: Protocol needs to generate content that is accessible to systems with keyboards.
21:18:38 [mcmay]
mb: We can't mandate a keyboard, but can make it possible.
21:19:27 [mcmay]
mb: Do we need to refer to UAAG if we say section element must be focusable?
21:19:29 [mcmay]
rs: no.
21:19:55 [mcmay]
Melinda Grant (mg): What about printer devices?
21:20:21 [mcmay]
jg: We have "implement acc. features of specs". That could be considered an acc. feature of the spec.
21:20:41 [mcmay]
jg: Could have an appendix saying "these are the acc. features."
21:21:46 [mcmay]
mb: Should add to our spec, headers must be focusable, then say in appendix that we conform to 9.9 of UAAG?
21:21:47 [mcmay]
jg: yes.
21:22:00 [mcmay]
s/headers/section/
21:22:27 [mcmay]
mb: Another question of whether devices have to support focus.
21:23:21 [mcmay]
sp: So since you don't support focusable, don't need to support by UAAG.
21:25:18 [mcmay]
jg: UAs that support screen, braille and speech apple?
21:25:29 [mcmay]
pk: No. Say, is this a user agent or something else?
21:25:53 [mcmay]
sp: Google is a UA to us. Follows processing rules of HTML.
21:26:44 [mcmay]
sp: If it's pretending to handle the content, that's our definition of a user agent.
21:27:56 [mcmay]
pk: Separate agent from user agent?
21:30:32 [mcmay]
cl: UAAG and XHTML 2 are two different specs.
21:31:06 [mcmay]
jg: Don't want to make it easy to get out of UAAG, or put it off.
21:31:14 [mcmay]
mb: We should really be doing this appendix.
21:33:07 [mcmay]
jg: There's agreement that desktop browsers should conform to UAAG. The outliers (printer, refrigerator) notwithstanding, we should push people to conform to UAAG.
21:34:11 [mcmay]
jg: Take a class of "desktop" for normal browsers, e.g. "utility" for others.
21:34:28 [mcmay]
pk: There's parsing the protocol, then being a validated presentation of the protocol, which means meet UAAG.
21:34:42 [mcmay]
sp: Could be possible.
21:35:02 [mcmay]
rs: We could go through the UAAG requirements, list what is required to do that.
21:35:59 [mcmay]
sp: One of the reasons of XHTML 2 is easier and better accessibility.
21:36:25 [mcmay]
sp: So it's absolutely understandable. We want to encourage accessibility as far as possible. Need a consensus position where you get what you want and we get through CR.
21:37:33 [mcmay]
pk: is there a situation where we can be hardnosed? e.g., a printer with a screen and a keyboard.
21:37:48 [mcmay]
mb: Printer display could be just a small LCD.
21:38:05 [mcmay]
mg: Printer could allow document to be displayed to LCD, and maybe interact.
21:38:42 [mcmay]
jg: UAAG wasn't thinking about a refrigerator.
21:38:55 [mcmay]
sp: Could be that UAAG's UA is different from XHTML's UA.
21:39:09 [mcmay]
mg: New devices may deserve a new term other than UA.
21:39:35 [mcmay]
jg: Could limit scope to a set of devices.
21:40:11 [mcmay]
mg: Or "as fully as possible"?
21:40:18 [mcmay]
pk: No, that's subjective.
21:40:52 [mcmay]
sp: answer to "is h element required for a section" is no. We're only applying facilities.
21:41:12 [mcmay]
mb: Section may not have any rendered consequence.
21:41:15 [mcmay]
cl: Could have a title?
21:41:19 [mcmay]
sp: Could have a role...
21:41:29 [mcmay]
mb: Could be for the author's convenience to have n sections.
21:42:16 [mcmay]
jg: Section is implying structure while div is more stylistic.
21:42:27 [mcmay]
sp: Disagree.
21:44:03 [mcmay]
jg: abbr expansion?
21:44:08 [mcmay]
sp: possible in style sheets.
21:44:18 [mcmay]
jg: If UA came with default alt stylesheet.
21:46:11 [mcmay]
jg: I don't think it needs to be a requirement of the UA.
21:46:35 [mcmay]
jg: Doesn't have to be a required feature. But useful.
21:47:01 [mcmay]
sp: You'll see we don't specify presentation rules. We do have a default stylesheet in the back.
21:47:07 [mcmay]
cl: No techniques document to go along with it?
21:47:10 [mcmay]
sp: Not yet.
21:47:53 [mimasa]
(FYI, "XHTML Ruby Support" provides an option to render abbr's title as ruby: http://piro.sakura.ne.jp/xul/_rubysupport.html.en )
21:47:55 [mcmay]
sp: cite is a particular case of metainformation. You can add metadata much more widely in XHTML 2 than HTML 4.
21:48:27 [mcmay]
jg: What's its navigation mode?
21:48:33 [mcmay]
sp: none. That's the case with all metadata.
21:48:47 [mcmay]
sp: If the intention is navigation, then you put an href and a cite.
21:49:57 [mcmay]
sp: href and rel="cite"
21:50:08 [mcmay]
mb: Could use dc:creator as well.
21:51:21 [mcmay]
rs: longdesc replaced with container element ("<p src="foo"></p>") so there's the possibility of rendering beneath.
21:51:57 [mcmay]
jg: possible to disable access element?
21:52:08 [mcmay]
rs: can let UA assign it.
21:53:07 [mcmay]
sp: I heard you wanted id in access.
21:54:21 [mcmay]
rs: UA solves key conflicts.
21:54:28 [mcmay]
jg: How does the UA communicate to the user?
21:54:45 [mcmay]
rs: will have to bring up a dialog.
21:54:53 [mcmay]
sp: addressed by UA.
21:55:54 [mcmay]
rs: I also mentioned an idref. Still needed?
21:56:00 [mcmay]
cl: No, because now we have targetrole.
21:56:47 [mcmay]
jg: does default styling mode reference keyboard?
21:58:30 [mcmay]
jg: Could create a best practices document for this.
21:58:57 [mcmay]
mb: XForms hints. Concept of an ephemeral message, like a tooltip, but in a voice context, what does that mean?
22:03:05 [mcmay]
jg: Can XHTML tables still be used for layout?
22:03:13 [mcmay]
sp: It's not the intention, but you can't stop people from doing it.
22:09:31 [jessie]
jessie has left #ua
22:14:09 [mimasa]
(re tables: in XHTML2 you can't even set border nor width without style sheet. It's still possible to abuse them, but I guess there's less motivation to do so)
22:14:24 [mimasa]
mimasa has left #ua
22:19:52 [mdubinko]
mdubinko has left #ua