Minutes, sub cmtee meeting 060407

Agenda

Item. Improved focus navigation (nextfocus, Z-Order, relationships)

Item. Relationships (Creating potential navigation paths through the presentation)

1 Roll Call

DISCUSSION: No apologies.

2 Improved focus navigation

DISCUSSION: RS. How to improve focus in presentations. Also drawings in text documents. No predefined navigation order. Same in other office formats.

CA. If using tab, only get access to attributes. 2 ways to read. In slide show mode (in powerpoint), or via edit mode. Most use traditional mode. If edit mode, can move among shapes using tab. Then use up down to read contents of shape. kbd is specially set up for jaws. Normal mode=slideshow, F5 or F9 for edit mode. In slideshow mode, edit not possible. View only mode. Limited kbd use. slideshow mode is complicated. Does not show all content.
TI. Jaws optimised for screen mode. Assigns some kbd nav functions. Thats how slide mode used.
PK. F5 in slideshow is different to CA described mode. Suggest we do not copy Jaws mode but provide the same functionality.
RS. We should focus on normal mode. XHTML facility, can change the tab order, using id values. This is for navigation within a single slide .
PK. suggest we ensure we understand UI requirement. Maybe outline mode is best for viewing. We can put text in many places which are not part of the outline. E.g. title and content, also text boxes 'anywhere'. These do not appear in outline mode. Need another view to get all text. This works in slides now.
CA. We (Doc Explorer)have a function to extract all information in slide. Users like to read text information. Don't like to have to use edit mode.
PK. Outline mode would probably be preferred but there are all kinds of ways to put text on a slide that are not part of the outline. Text in text boxes doesn't appear in outline mode. Doe we want a special mode of outline mode that simply extracts all the text? In OO/SO normal mode for slides you can tab element to element, hit enter to enter an object then esc to exit. It is more cumbersome but it does give you access to everything.
DP. Do we need to differentiate between editing and viewing?
PK. There are multi-views optimized for a particular function. In normal/outline mode can edit, other modes can't edit. Does it make sense to have one mode optimized for blind user to nav/edit/read/etc, or keep what we have and use outline mode. It's better than using XML.
CA. Two discussions. How to get next focus, How to provide user interface. If next and previous focus(n/p), basic problem solved, UA can provide UI for screen reader.
PK. Not convinced. How will n/p focus help? Anything you can manipulate is already in tab order. unsure if that's the most logical order is questionnable. To is creation order or l-r t-b order. C with n/p tags. How does user manipulate these? E.g. bring front send back impact?
CA. Tab order is creation order. XML order == creation order. Think it's hard for author to add tags.
PB. Can change order by editing. Also think we don't need special text for that.
CA. It is compliciated to authors to add tags, but with z order authors wont bother either.
PK. Why is it important that order z order be done like this? Can use screen coordinates. But more importantnly first need to understand what user experience should be.
RS. In edit mode z order has no logical navigation, no good association. It's disorienting. In presentaiton mode ATVs use coordinates.
PB. If someone wants to edit it, whats wanted? No logic. In presentation mode, they take the objs, sort for navigation.
DP. When describing diagrams for audio, look at diagram very quickly and what you remember is what you describe fisrt and that should be first in tab order. Reiterate to determine what else to is important to describe next and put it next in tab order. For SVG example, used a street map of city. made it accessible by annotating groupings of lines/objects and giving them a tab stop. Need skill of someone used to describing presentation for audio desc
PK. Agree draw order is irrelevant. We're blazing new ground. Could we look at media obj ideas. We could layer on top. Another layer for 'interesting bits'. E.g. tiger. 80 elements make up face. Shouldn't worry about tab order for ind items. For that class of app, we need to layer another meaning. Also a mostly simple slide, with other elements. This more common, we need a way of getting meaning. We'll want to use jaws cursor or editing mode.
DP. Suggest we gather examples of different kinds of slides. Try producing a means of navigation, getting at info, means to change mode to fix ordering.
PK. Need a flat mode and an editing mode. AT would walk tree and order l-r t-b
DP. Could be a problem in ordering l-r t-b
PK. Yes, might want column nav, or the ordering of groupings in the tiger might be independent of location.
DP. Want higher level slide to slide nav, lower level nav between notes and slide, lower yet within parts of presentation
PK. Already have unordered content we need to deal with. Need to deal with this legacy content.
PK. Historical problem with authors with no experience of how to make drawings work. (Education missing). Must be able to cope with these slides. Slides are created quickly, edited by many people with visual appearance as goal. We need more general approach for most slides.
DP. Can we help with Education &Outreach, as per WAI model?
PK. Flexible charter. Could do it. Advice to adoption TC. Could extend to all aspects of the suite. Should be topic number two after July. We could suggest a priority order. Focus now should be for bulk of slides in wild, by minimising author input, max app task and AT work. Mass percentages. ...? For K workers, lot more slides seen. Especially from senior people. Asking them to optimise for a blind person unlikely. Slides are ephemoral. Need to minimise additional work on authors.
CA. Are we saying we need to figure out a nav order automatically?
PK. Docs are mostly text, 50% spreadsheets, very few slides. Investigation of how slides are created would be helpful. We should spend most of our time on AT improvements of handing existing slides.
RS. One reason slides are not used by PWB, slides are so bad, they can't participate. Presentations are used far more in workplace. What can we do automatically. E.g. 2 obj and connector, unlikely to see relationship. Could help author to note that relationship. E.g. connectors in OO, different from a line. Glues two obj together. Could we use that for autotagging?
PK. Would need tool to ask for src and dest
RS. Lines with dots are used to glue stuff together; then have connection and can autotag. However, XML doesn't show this relation info. Would this help?
PK. This is a corner case. Multi columns, multiple text boxes are common cases. We should look at these first. Assessing slides, amount of meaning, will find text in template, in text boxes, Then drawings with and without glue points. Hard to get meaning from those.
RS. Didn't mean to imply that this was a priority. We do need to get some examples, categorise types of layouts.
PB. When presenting, should we categorise types of layouts?
DP. On a slide complex objects are lower priority for user ot focus on, simple objects are higher priorty for a user to focus on. A good test of presenatoin is if you can describe it without someone seeing the slide.
PK. How many were created with standard layouts, how many put there randomly. We could use standard templates with good accessibility! Then move to author advise. Work with users and categories of slides and analyze. At process level, sit down with exp blind users, test out our logic.
CA. For quick soln, we don't care much for diagrams, or complex images. We want all text information.
CA. For quick soln, we don't care much for diagrams, or complex images. We want all text information.
PB. We want order of text info to be comprehension order. Could be grouped l-r t-b. Thre is a canonical composition. Simple flat review not right. But at first level decomposition. Then traverse into objects.
HT. Also need to address grouping. Sometimes templates.
PK. Grouping may be created for me. Inserts naturally group things. E.g. a table. A semantic single entity.
HT. Could use grouping for tab order and next focus.
PK. Some structure is provided by templates, e.g. two cols with text on top. Grouping may be created for me. Inserts naturally group things. E.g. a table, a chart. A semantic single entity.
HT. Could use grouping for tab order and next focus.
PK. Suggest we do a survey, then categorise them, try reading schemes, then try to do it automatically.
CA. Will UA provide such function?
PK. AT and UA between them. E.g. could decide that outline view of UA should show all text. That could be a best approach.
CA. What kind of text info do you provide in outline?
PK. Prose text in a natural order. In diagrams, text boxes are more common. E.g. Sun standard has 1st and last as text boxes. Rest are main body text?
CA. Can I get layout (indent) information?
PK. But we can't come to an answer until we analyze slides. But in my presentation slides at CSUN there is a time line slide. It's just a bunch of text boxes and not accessible. We could do some analysis. We can get font sizes. We could do some analysis.
PK. A timeline slide from CSUN was all text boxes, grouped for alignment.
PK. Is this a big enough task under an RERC? A US grant system for studies.
DP. We need to get the question right first. Try it ourselves first?
CA. Should we do this?
All agreed.
DP. What are our deliverables?
RS. We've addressed most of the gaps, except for tables. Why can't we try to make progress now to June. We have some internal research around this, due Sept.
RS. Call next week? Address CA question? PK No. add to normal telcon.
PK. Add my output from yesterdays action to agenda. Suggest that priority one is ODF spec change for June. two, adoption guidance. Three deeper raising the bar. Sooner advice is out, sooner it can be deployed.

Action item: Decribe problem

Who? DP

Due date: Next week.

Action item: Check back with CA gaps

Who? RS

Due date: Next week

RS posted the following to the list as a discussion document. W3C

nextfocus = IDREF

This attribute specifies an IDREF of an element in the current document that will receive focus when the user requests that the user agent navigate to the next element that can receive focus.

The sequence of focusable elements is called the document's navigation order. The navigation order defines the order in which elements will receive focus when navigated by the user. The navigation order may include elements nested within other elements.

When a document is first loaded, a user agent must do the following:

1. If a document is loaded using a URI that includes a fragment reference (such as book.html#chapter5)

1. If the fragment reference identifies an element in the document, the user agent must ensure that navigation starts at the beginning of that element.
2. If the referenced element is focusable, that element receives focus.
3. If the fragment reference does not resolve in the document, the user agent must ensure navigation starts at the beginning of the document.

2. If there is no fragment reference when the document is loaded:

1. If the root element of the document has a nextfocus attribute, and the element referred to by the attribute is focusable, the element must receive focus. The user agent must ensure the beginning of the element is visible on the display.
2. If the root element has no nextfocus attribute, no element receives initial focus. The user agent must ensure navigation starts at the beginning of the document.
3. If the user has moved away from the initial navigation point of a document (e.g., through using page up and page down or by changing focus), refreshing the document should result in the user's navigation location being preserved.

In the event no element in the document has focus, when the user requests the next focusable element, that element must be the next focusable element forward from the current navigation point in document order. If there are no focusable elements before the end of the document, focus shifts to the first focusable element in document order. If a document has no focusable elements, then no element receives focus.

Once a focusable element in the document has focus, upon requesting that focus change to the next focusable element, the user agent MUST follow these rules when determining where focus is next set:

1. The next focus of an element without a nextfocus attribute is the next focusable element in document order. If there are no remaining focusable elements in document order, the next focus must be on the first focusable element in document order.
2. The next focus of an element with a nextfocus attribute is the element referenced by that attribute if it is focusable, otherwise the next focus of that element.
Regardless of the way in which an element receives focus, if the element is not currently visible on the user agent's display, the display must be updated so that the element is visible.

The following example would allow the links to be navigated in column order (without the use of nextfocus they would be navigated in document, i.e. row, order):

Example

           <table>
            <tr><td id="a" href="nw" nextfocus="b">NW</td>
               <td id="c" href="ne" nextfocus="d">NE</td></tr>
            <tr><td id="b" href="sw" nextfocus="c">SW</td>
               <td id="d" href="se">SE</td></tr>
            </table>

Navigation keys. The actual key sequence that causes navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key might be used for navigation and the "enter" key or "space" key used to activate a selected element).

prevfocus = IDREF

This attribute specifies an IDREF of an element in the current document that will receive focus when the user requests that user agent navigate to the previous element that can receive focus.

In the event no element in the document has focus, when the user requests the previous focusable element, that element must be the next focusable element backward from the current navigation point in document order. If there is no such focusable element back to the start of the document, focus shifts to the last focusable element in document order. If a document has no focusable elements, the behavior is unspecified.

Once a focusable element in the document has focus, upon requesting that focus change to the previous focusable element, the user agent must do the following:

1. If the focused element has a prevfocus attribute that references a focusable element, focus is moved to that element.
2. Otherwise, focus shifts to the previous focusable element in document order.
3. If there are no previous focusable elements in document order, focus shifts to the last focusable element in document order.

Regardless of the way in which an element receives focus, for visual user agents, if the element is not currently visible on the user agent's display, the display must be updated so that the element is visible.

office-accessibility message

OASIS ODF Accessibility SC Meeting

Attendees

Agenda

1 Roll Call

2 Improved focus navigation

Summary of Actions