Ad hoc HTML A11y TF F2F Day 3 -- 17 Apr 2015

CMN: I want a solution that just works. No need for a handler script.

RS: Need to know what the access key does, as well as the fact it's there.

CS: When a user triggers the accesskey, you're invoking the action?

CMN: Yes.

Lots of opinions on whether to move to the element, or move to the element and activate it.

RS: Default action could be to move focus?

CS: Suggest leaving default action to the browser.
... Important that behaviour in browsers that ship with OS browsers is consistent throughout the OS.

JS: Would be useful if a user could initiate a focus change to a specific element, where navigation might otherwise be slow. The second row in a table for example

CS: A macro?

JS: Yes.

CS: Feels like an add-on.

CMN: Yes, but it would be trivial to do.

Don't want to insist on it being default browser behaviour though.

CS: Think there is a set of things that should just have standard keyboad behavour - different across platforms, but consistent functions - undoo for example.

CMN: Roughly speaking, if we had discoverability, browser interaction assignment, then that's necessary and sufficient to make it workable. Eveything else is enhancement.

RS: Think we can get the browsers to do it?

CMN: We don't know.

RS: Could do it in SVG?

CMN: Have it in HTML5 - want to redo it there.

CS: Would need multi-key shortcuts - for Ofice online for example.

<JF> Current HTML5 spec: http://www.w3.org/TR/html5/editing.html#the-accesskey-attribute

CMN: If you have accesskey="a b c", but "b" and "c" are not available, the browser would choose an alternative available key.

CS: Trying to find keyboard events spec which might have useful info.

CMN: Look in DOM 3 events.
... The shortcut calculation in the browser would work something like the accesible name computation.

RS: We want browsers to assign keys for common functions?

JF: One potential problem is that the browser might not know what an AT is using.

RS: This is where whatever we do for these interfaces, we can implement an accessibility API mapping for the AT to use.
... We do this - like go and find the submit button and kick it.

CMN: Things like send, reply, undo etc. doesn't need accesskey, the browser provides that shortcut.
... To JF's point, think it's better to connect the AT and the browser, not the AT and the website.

RS: Do we want to identify these common controls?
... Do we want roles, or something else?

CMN: Role would work, but don't want to focus on that now.
... An alternative would be the actions stuff in schema.org.

<JF> Schema.org Actions: https://schema.org/Action

CMN: The mechanism we use for identifying standard roles, is a more general exercise than a bunch of accessibility people.

JF: Schema.org has lots of possible common actions.

RS: Action items?

CMN: Go out and convince people about this.
... This is one part of the keyboard interaction stuff we looked at earlier.
... File browser bugs.

CS: We'd need something more defined before we could file a bug.

CMN: Yes. Keep scribbling in the wiki.

<chaals> [adjourned]

<cyns> To report IE bugs: https://connect.microsoft.com/ie/

<cyns> To request IE platform features https://wpdev.uservoice.com/forums/257854-internet-explorer-platform

CMN: With Web RTC is there a data channel in addition to the audio/video feed?

JS: Yes, they did spec one.

JF: What, if anytihng, should we look at?

JS: There is a lot. We should walk through the spec.
... Support for multiple video streams - to support main channel in addition to a signed channel for example.
... It'll be a major effort for APA/PF, probably second half of this year.

JF: Specifically there is a request for feedback on media capture and streams.

JS: We'll do that. Shane and I have an action to write a note to the TAG. Shane and I are working on an overall strategic vision - that could be presented to the TAG.

CMN: My concern is whether you can do text chat. If you do screencasting is it clear how you pass objects like text.

JS: One of the APIs talks about passing DOM objects across. Others will be bit-mapped - like streaming webcams.
... Which for webcams is ok, but for screen-sharing we need objects.

JF: We would like support for objects, we can't force two people to use them though.

JS: Yes, good refinement.

Web VTT

JF: We've been asked to review the Web VTT spec.
... A lot was developed with FCC requirements in mind.
... Silvia Pfeiffer and Dave Singer were involved, so there were people with accessibility experience.

SH: CSS extensions were a concern. Had issues trying to figure it out, but don't know whether they were fixed. It's been a long time since I've looked at the spec.

Walking through te spec...

JF: The snap to lines flag is new.

JS: That's an FCC requirement?

JF: Believe so.

JS: There are issues for magnification with snap to. Has that been talked through?

JF: We'll flag it.

SH: Was concerned about how they computed the size of the box. How you position the box was dependent on the size of the box. Might have raised a bug. Don't recall now.

JS: The media Access user Requirements (MAUR) included htis as a requirement I think.

JF: That would be a UA thing.

SH: They made it so that if you popped something, it would push existing content up. This made htings difficult because it forced you to move along before you consumed the content.
... It means your stuff could be moved some place you weren't expecting. Trade off do you read the text but in a strange place, or do you force the text position.
... It's on a per cue basis, so this also means moving text could change the meaning of the text.

CMN: End alignment - given a box how do you anchor something within the box.

JF: Positioning of the text track box is based on the size of the video rendering screen. What happens with screen magnification?

CMN: You can define a region for the captions. Question is if you zoom, can you readjust the region to stay within view?

SH: Not if you only zoom text.

CMN: It is a problem with zoom - if you zoom until the captions are out of view, that's an issue.
... Need to tell the captions to remain within the magnified viewport.

JS: User should be able to control/adjust the amount of space taken up by the video and by the captions respectively.
... Would the requirement be that the two areas adjust based on some kind of algorithm?

JF: Ability to resize is in the spec.

SH: Should be an option to define it based on other parameters?

JF: Yes.
... This may already allow that to be done.

CMN: Question is how to you comunicate the fact there is a clipped view region?
... Text Track Regions may be relevant here?

SH: Can the region be animated?

JF: CSS?

SH: It isn't a CSS property so I don't think so.
... This spec is written very operationally.
... It's a spec for the person developing the parser, not the payload.

CMN: Makes it unreadable.

JS: We could ask them to provide better explanations?

JF: Text review position cue setting - seems the adjustment of the video/captions boxe seems relevant
... Anything on parsing?

CMN: We're assuming they have it correct.
... Section 6.1 is broken. We should let them know.

SH: The audio element has nothing to render, so in this instance there shouldn't be any use of the audio element, only the video element even if oaudio only content.

CMN: Hmm. So if the content is audio only there can be no captions? That's an issue.

SH: If there is no rendering area there's nothing you can do.

CMN: Right, but automatically choking on audio is not good.

SH: The rendering of the audio element was a decision by the HTML WG.

<JF> If the media element is an audio element, or is another playback mechanism with no rendering area, abort these steps. There is nothing to render.

CMN: The "nothing to render" part is incorrect. There is stuff to render.
... If there is no rendering area, the process should say "panic and find one".

<JF> If the media element is a playback mechanism with no rendering area, panic and inform user.

JF: I have a concern - they talk about CSS values, but I don't see anything that links CSS to the Web VTT file as opposed to embed it.

SH: The CSS used to come from the HTML doc, but they're working on changing that.
... They have their own sub-set of CSS.
... Interesting that you can interact with captions through scripting.
... Probably the only way to realy critique this is by trying to implement it.

JF: A joint meeting would be good - either on the phone or TPAC?

JS: We need to give comments in the next week or two.

SH: I can find the comments noted on older versions.
... Will send to Cynthia to circulate to TF.

JF: Still concerned about the CSS.

SH: Also which takes preference embeded CSS or CSS from the HTML doc?

JF: Concerns about need to overwrite inline styles.

LW: Think most browsers allow inline styles to be overriden now.

CMN: Don't think so.

SVG navigation strategy

RS: In SVG tabindex is good for some things. If you have focus in the middle of a complex drawing (like a flowchart), you have to take decisions about where focus should move next - it may not be a linear navigation flow.
... We want to find out a way to provide navigational direction on screen. For example, based on compass points.
... Problem with that is that it can be restrictive - what if you miss something in between?
... On some mobile devices there is the notion of a roter. You can rotate around the point you're on, and you can then pick an option.
... Can we leverage this approach? The ability to rotate 360 degrees, and from there choose a direction.
... We have SVG Connectors and ARIA semantics. The suggestion is to make anything that doesn't default to role="none" focusable.
... Then when using a roter to identify objects in the vicinity of the current focus point, you can pull information about those objects - like role.

<scribe> scribenick: LJWatson

RS: This removes the need to use tabindex.
... The other thing is that not everything will be visible on-screen at once. There might be "drill down" information available in the SVG.

JF: It's almost 3D?

RS: Yes.
... You don't need to use a finger to use the roter, you could use other input devices.

CMN: Take the old text-based adventure game model.
... You are in a room, there are exits to the north, south and west.
... It's the same model. Plus the ability to move back a step. Directions like take me back, take me up etc.

RS: Objects don't need to be "line of site".

CMN: Some times you want to move through connected objects - like a lfowchart.

CS: There are several ways you want to navigate a diagram - one is by semantics, another is 2D space, another is 3D.
... Another is by linear path.
... Having this at a markup level makes sense, designing UI is not soething W3C should be doing.

RS: We need to do something feasible.

CMN: So we need to think about feasible UI implementation.

CS: Does the roter does something other than semantic XYZ?

RS: In SVG you can have multiple paths that form a collective. You don't want to visit each of those objects.

CS: Smart Art uses a tped directional graph to represent semantics, then renders that as graphics. Does SVG have that?

CMN: It does now with Conectors.

CS: Those are fairly rudimentary.

CMN: SVG content can have title, desc and metadata.

CS: So only semantic things are grouping and connectors?

CMN: Yes. Composition model is you paint in source order. Group 1 gets painted first, then Group 2 gets painted over the top of Group 1.

CS: You could build an acc tree based on groups and connections?

CMN: Yes. Having Connectors means you can build a directed graphi.

CS: Connectors are not typed?

CMN: No, but if you use metadata you can attach typing to them.

CS: They can be bidirectional.

RS: Believe so.

CS: Translating diagrams into trees is difficult.

CMN: Building an acc tree from SVG grouping is ok because it's a tree.

<joanie> why not use flows-to/flows-from relations, and child-of/parent-of relations?

<janina> ok

RS: To Joanie's comment - would need to be parent/child.

CS: Would want to see connected-to and connected-from.

Cynthia demonstrating Smart Art content.

Smart ARt lets you translate the list of content into different forms - graphics. It uses the basic hierarchical relationship.

CS: Different layouts.

JF: So the key is to preserve the semantics?

CS: Yes, the underlying relationships between the modes doesn't change.

RS: You should join the SVG A11y TF Cynthia.

CMN: Check out the SVG wiki.

https://github.com/SVG-access-W3CG/use-case-examples/tree/master

https://www.w3.org/wiki/SVG_Accessibility/ExampleImages

CMN: There are a few different ways you want to navigate through a graphical object.
... Navigate according to connected objects. For example a circuit diagram.
... Navigate by "go back" "go forward" model.
... Navigate by linking - <a href="">. Treating that as a connector, it's how the web works.

CS: So two kinds of connectors?

CMN: Yes.
... You can't get the graphical layout - "up here there is X".
... The tree and painting model allows 3D navigation.
... There's no way to indicate that though.

CS: PowerPoint works in a similar way. Source order is based on order content was added to the canvas.
... Screen scraping is what the ATs do, but we don't want to encourage that.

CMN: SVG objects have a bounding box. You can query the parameters of the bounding box.

CS: Seen some examples of graphic navigation using cursor keys, or compass points.

RS: Don't want to limit it to compass navigation.

CMN: No. A map - ask what is south of the North West Territories? Answer is "everything".

CS: You could include the compass points in between.

CMN: Excet if you have a four point directional thing, a lot of time up is up a level, down is down a level, and left/right cycle through options.

CS: You could introduce a proximity connector, which is directed.

CMN: Can do navigation on the basis of metadata, or tabindex.

CS: But metadata isn't defined.

CMN: A product based on metadata shipped today would make no sense.
... Need to identify ghe groups that are meaningful, perhaps because they have title and/or desc.
... Sometimes you want to navigate semantics, sometimes by the layout.

RS: In SVG 2.0 elements that don't render default to role="none".
... audio and canvas have role="group". Anchor has role="link" etc.
... The default to role="none" stops the accessibility tree from being disproportionatly big.

CS: Is there a circle role, a rectangle role?

RS: That's what we're creating. We have use cases so far.

CMN: Should there be a desc role?

RS: No, it maps to accessible description.
... You don't have a stand-alone desc, I don't think?

CMN: A stand alone label perhaps.
... What about title?

RS: Title would be part of the name computation, not considered an object.

JF notes that Ann has sent through some SVG examples.

JF: Complex diagram of aircraft.

RS: This is why you need the roter navigation strategy.

CS: There are obviously connectors in this diagram.

CMN: Yes, and obvious groupings.

JF: Explanation in email from Ann, coloured bubbles let users mouse over objects for more information.

LW: Is distance going to be important?

CMN: Yes.

JF: Scale rather than distance.

RS: Not sure what's important to someone going through a drawing.

CS: The author wil know.

CMN: More tricky than that - what someone wants will depend on what they're using the drawing for.

RS: There is so much information in these diagrams - size, length, shape etc.

JF: Need an overview of the thing, then more information.

LW: Doug's demo Scriblr uses a drill-down feature that would be a good way to provide more detailed information about objects within the SVG.

RS: From authoring - how does an author know whats important to convey?

CS: The autor should know.
... People who think in terms of pictures often find writing difficult.

CMN: Good thing about SVG is that you can continue to label and annotate it.

LW: What about tagging an object so you can return to it later?

CS: That would be a browser function.

LW: Hardest part of this is keeping the information in your head.

CS: Ability to navigate with arrow keys is likely to be useful to everyone.

CMN: Big part of the cognitive is de-mystifying the "mystery meat".
... There are commonalities between issues for people with cognitive disabilities, and visual disabilities.

SVG next steps

CMN: Added diagrams and documents to the SVG wiki. Links previously posted in the channel.
... We have a colection of SVG. We want to look at them and ask how we deal with different kinds of image.
... The SVG is also on Github. Links previoulsy posted in the channel.
... Want to iterate on those and make the examples as accessible as we can. Then take the Github change notes, so we can look for patterns of changes - like every SVG had the <title> element added for example.
... We'll then also have a collection of good accessible SVG examples.

RS: We could take Describlr and create examples based on the knowledge we gather from this exercise.

CS: Will lok at Visio - it has create SVG templates that might let us create some other examples to work with.

RS: We have a business need for this at IBM. Perhaps Boeing would be interested in joining too.

CMN: The wiki structure is that SVG is grouped in categories - like directed graphs.

- DRAFT -

Ad hoc HTML A11y TF F2F Day 3

17 Apr 2015

Attendees

Contents

Web VTT

SVG navigation strategy

SVG next steps

Summary of Action Items

Scribe.perl diagnostic output