- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 21 Apr 2015 15:17:08 -0400
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Colleagues:
Minutes from the HTML-A11Y Task Force Face to Face meeting on Thursday
16 April are now available:
http://www.w3.org/2015/04/16-html-a11y-minutes.html
W3C
- DRAFT -
SV_MEETING_TITLE
16 Apr 2015
See also: IRC log
Attendees
Present
JF, RichS, Léonie, Cynthia, Janina
Regrets
Chair
chaals
Scribe
Rich, chaals, JF
Contents
* Topics
1. transcripts...
2. Keyboard
3. WAPA
4. Testing
5. Accesskey
* Summary of Action Items
* Summary of Resolutions
_________________________________________________________________________________________________________________________________________________________________
<chaals> RS: Are you testing HTML5 and ARIA 1 or 1.1?
<chaals> CS: Looking at the mechanisms - the actual test cases is a matter of typing
<chaals> CS: We don't want to repeat the experience with testing ARIA 1.
<chaals> [some agreement that it was less than joyous]
<chaals> RS: Had problems getting good test cases.
<chaals> ⊠about 800 - I personally wrote or rewrote 600
<chaals> JF: So you write 200 more and we're done, right?
<chaals> CS: We can get developers to make tests if they have an automation infrastructure.
<chaals> CMN: review WebVTT?
<chaals> JF: Would be good to do it somehow.
<chaals> JS: It's a general request, and we agreed that we would look feature by feature comparing it to MAUR.
<chaals> JF: A lot of the work is looking to replicate what FCC requires on screens, but basically it is a timestamp format, so I don't see a lot of other issues.
<chaals> RS; Nor I
<chaals> CS: There is formatting.
<chaals> ⊠saw it hard to meet CVAA.
<chaals> JS: If it doesn't have enough it won't meet MAUR.
<chaals> CMN: will aim for tomorrow on navigation model
<chaals> CMN: Plan fo today: transcript, keyboard, WAPA, lunch, WAPA, testing maybe WebVTT?
<chaals> ⊠for tomorrow: navigation models, Web RTC, panels, maybe stuff from date pickers, SVG
transcripts...
<chaals> CMN: Met yesterday with HTML MediaâŠ
<chaals> minutes of yesterday's discussion.
<JF> Proposal presented yesterday
<chaals> CMN: Rough summary. We took the document into the Media Task force, and asked if we were insane to be asking for a linking mechanism as a child element of
video, and for a transcript container element.
<chaals> CMN: My summary of the feedback is roughly:
<chaals> ⊠No, the linking idea isn't insane, should you use source element? Or track - maybe / maybe not.
<chaals> ⊠We need to look at use cases for video like MSE and spliced advertising and say what happens.
<chaals> ⊠We should consider a best practice of what the target format will be and ways it gets rendered.
<chaals> ⊠my sense is that means we should describe our assumptions better.
<chaals> JS: What happens to described video when advertising is playing?
<chaals> CMN: ⊠We should present this stuff when cleaned to the HTML group, Web/TV IG, maybe ask TAG to look at the linking structure and say yeah that makes sense.
<chaals> ⊠In summary, people thought we were on a reasonable track
<chaals> [generally agreed]
<chaals> JF: My sense was that using track @kind was a reasonable solution.
<chaals> CMN: Other suggestion was source - an argument being that its basically a first-class source more often than it is an additional / supplementary resource.
<chaals> ⊠We should not "bikeshed" here.
<chaals> RS: Harvard were doing transcripts. Wasn't sufficient for the classroom. Want captions more than transcriptsâŠ
<chaals> ⊠making it a first-class thing doesn't make a lot of senseâŠ
<chaals> ack
<Zakim> janina, you wanted to revisit transcript with time stamping
<chaals> JS: when this was debated similar stuff came up. The source was being proposed by one side - people just want to go through the transcript faster than the
media source. The other proposal was getting timestamps, so why would we need captions.
<chaals> ack me.
<chaals> CMN: Best practices for transcripts includes having the information you need to replace the video, not just the audio being transcribed - although sometimes
all you get is the text out of the captions with no timing. Some use cases are just read the thing, but others are an interaction making use of timing information to
link back to relevant points in the video - or even search through it in real time instead of just fast forward / rewind style time hunting
<chaals> JF: Part of the problem is that the definitions, especially for transcript is loose.
<chaals> ⊠WCAG @@ calls for media alternatives, whereas another bit just calls for captions.
<chaals> ⊠I have seen people use a caption file with some extended description, called a transcript.
<chaals> ⊠1.2.3 says a media alternative is good enoguh for single-A conformance - actual audio description is only required for double-A.
<chaals> ⊠Think WCAG is confusing by not talking about "transcript".
<chaals> ⊠uses "media alternative" - which is defined as time-based. A transcript without timing points isn't necessarily the same.
<janina> I believe JF's example "transcript" usage actually conflates the requirements of two different user groups, i.e. blind people don't use captions, bu do need
video descriptions, deaf/hh don't need video descriptions, but need captions
<chaals> ⊠what we have referred to earlier as a timed transcript, for some use cases.
<chaals> ⊠Think we need to address this definition question.
<chaals> CS: Maybe we should just describe what we mean.
<chaals> ⊠COuld be plain text, or something moreâŠ
<chaals> JF: There is an editor's draft of MAUR out for review. Maybe we should define transcripts there.
<chaals> ⊠not something we should do by revising WCAG WCAG
<chaals> CS: We can do it in a lot of places.
<Zakim> janina, you wanted to say that defining transcripts will happen by adopting an approach
<chaals> JS: Getting into defining before we figure out how to proceed might be a waste of time. All of the varieties are legitimate in some places - we should
collect those up and make things work for them all.
<chaals> ⊠Whether you can do good things with a smart transcript, or whether you just read the text more or less flat.
<chaals> ⊠easier to get simple rendering from rich content than vice versa.
<chaals> JF: Currently in MAUR we say⊠"full transcript supports different needs, isn't captioningâŠ"
<chaals> ⊠that might be enough.
<chaals> JS: Nobody kicked that
<chaals> CS: No problem with what is there. We should add some examples to show what we mean, because other people have different narrower definitions. We don't need
formal definition, just some examples.
<Zakim> janina, you wanted to ask chaals whether we've already defined what we mean by transcript in the maur?
<chaals> CMN: Need to look at revising the transcript proposal from yesteday, adding explanations of what transcripts might be, show how to use the proposal to meet
various use cases, and look at the MSE and spliced advertising cases in particularâŠ
<chaals> RS: Do you want WCAG to write anything about how transcripts should be supported, in future versions.
<JF> ACTION on JF revising the transcript proposal from yesterday due 05/01/2015
<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/WAI/PF/HTML/track/users>.
<chaals> CMN: Maybe, but we want to get the mechanism that describes use casesâŠ
<richardschwerdtfeger> ack
<richardschwerdtfeger> ack
<JF> ACTION JF adding explanations of what transcripts might be 05/01/2015
<JF> ACTION: JF adding explanations of what transcripts might be 05/01/2015 [recorded in http://www.w3.org/2015/04/16-html-a11y-irc]
<trackbot> Created ACTION-314 - Adding explanations of what transcripts might be 05/01/2015 [on John Foliot - due 2015-04-23].
<chaals> CMN: We dealt with teh issues of differnt use cases and different styles in yesterday's discussion, both in the media TF and as we worked up the proposal...
<JF> ACTION: JF revising the transcript proposal from yesterday due 05/01/2015 [recorded in http://www.w3.org/2015/04/16-html-a11y-irc]
<trackbot> Created ACTION-315 - Revising the transcript proposal from yesterday due 05/01/2015 [on John Foliot - due 2015-04-23].
<chaals> JS: 3 years ago this was contentious - is that still the case?
<JF> ACTION: JF show how to use the proposal to meet various use cases 05/01/2015 [recorded in http://www.w3.org/2015/04/16-html-a11y-irc]
<trackbot> Created ACTION-316 - Show how to use the proposal to meet various use cases 05/01/2015 [on John Foliot - due 2015-04-23].
<JF> ACTION: Chaals look at the MSE and spliced advertising cases in particular 05/01/2015 [recorded in http://www.w3.org/2015/04/16-html-a11y-irc]
<trackbot> Created ACTION-317 - Look at the mse and spliced advertising cases in particular 05/01/2015 [on Charles McCathie Nevile - due 2015-04-23].
<chaals> CMN: Essentially the feedback in the Media TF was that this is about right - get the details sorted and move it forward.
<chaals> [Léonie points to Sylvia's email from today]
<chaals> [10 minute break]
<richardschwerdtfeger> scribe: Rich
Keyboard
<chaals> The framing wiki page for this issue
<richardschwerdtfeger> scribe: Rich
<richardschwerdtfeger> chaals: Keyboard interactin is a mess. The standard way it is done is with JavaScript which is pretty fragile as there is no way to have
scripts talk to eacher to describe what they want to have done
<richardschwerdtfeger> chaals: there is no useful approach as keys are varied. It is impossible to find a key that is available everywhere
<richardschwerdtfeger> cyns: Short cuts and actions (keyboard) are different among web apps.
<richardschwerdtfeger> chaals: What I want to do is tie the different discussions together.
<richardschwerdtfeger> chaals: Rich is proposing something that is less brain dead that tabindex in the DOM
<richardschwerdtfeger> chaals: I donât know if we want to dive into it much but one piece is the access key
<richardschwerdtfeger> chaals: landmarks, etc. should not have access keys. those should be standard browser features
<richardschwerdtfeger> chaals: some functions will be defined in specific apps.
<richardschwerdtfeger> chaals. games also have specific actions.
<richardschwerdtfeger> chaals: I think we need to look at the pieces we put together
<richardschwerdtfeger> chaals: I want to seriously reduce the need for JavaScript to do keyboard interaction
<richardschwerdtfeger> cynthia: it is a lot of work
<richardschwerdtfeger> chaals: the JavaScript model is brittle
<richardschwerdtfeger> chaals: It should be a contract between the user an their agent
<richardschwerdtfeger> chaals: this will not be solved in the next 3 weeks. there have been a number of discussions
<richardschwerdtfeger> chaals: we need a very clear story of how you get there from here
<richardschwerdtfeger> chaals: we donât have one good set of use cases collected. this is a major gap
<richardschwerdtfeger> chaals: that is why I want to push this keyboard stuff in a wiki
<richardschwerdtfeger> chaals: people provide scripts to to do aria types of things
<richardschwerdtfeger> chaals: the accessibilty task force is tied to html
<richardschwerdtfeger> chaals: we need a place to tie all these together. It really does not matter where it resides
<chaals> [agenda note: WebVTT tomorrow at 10am]
<richardschwerdtfeger> chaals: there is the access element module from xhtml2 which is one way of dealing with it
<richardschwerdtfeger> chaals: we need to figure out a better version that is less device dependent
<JF> WebVTT link for review tomorrow: http://www.w3.org/TR/2014/WD-webvtt1-20141113/
<richardschwerdtfeger> chaals: mail apps are typically keyboard heavy apps for many users
<richardschwerdtfeger> chaals: I prefer to work the issues through documents
<richardschwerdtfeger> chaals: we are still at the point of looking at the landscape and writing it all down
<richardschwerdtfeger> cynthia: people who use input mechanisms that match the OS platform they are using
<chaals> scribe: chaals
RS: Keyboard support is the most expensive thing for accessibility implementation today.
⊠If we had design patterns for different widget types, and push the device dependency to the browser, that would be great.
⊠Solves a huge problem. Would help automate testing, too.
⊠THink that is the way to go. Look at design pattterns for menus, etc, and draw out the common threads - we might find them on OS platforms already.
CS: We can do that with platform menus, probably ARIA, there isn't an HTML menu. SO yes we have that for the platform
RS: Having higher-level commands and things that respond to that would be fairly easy.
⊠That would be a *big* win. The question is how you scale this across productionâŠ
⊠in ARIA the browser takes a lot of weight and you show designers the semantics. But we can't do that today with input mechanisms.
⊠I'm simplifying. But that type of discussion is something you could do, so you remove a pile of code from applications.
CS: Agree. Get pushback from product teams who want somethign fancierâŠ
⊠telling people to use standard controls doesn't always work - people want shiny extras.
<Zakim> janina, you wanted to ask that we include D-Pub-type structures in the model, not just app widgets like checkbox, menu, etc
JS: There are other places we should be looking to source use models and interaction examples.
[+1]
RS: We need to allow for customisation.
⊠something liek control patterns, can you aply them to a new custom control
CS: That's what they were designed for⊠although there might be missing pieces when we look deeply.
⊠UIA separated visuals from user interaction to dothat.
RS: Let's say we had, for certain types of objects, "here are the design patterns you need to apply" and they come 'off-the-shelf' instead of having to be built each
time from scratch (or in a library)
⊠So you need to have discoverability of what things can do
CS: Which is better than having to agree on what something "is" - that's much harder.
⊠telling designers that their fancy new thing is just another menu doesn't make the conversation start well.
<inserted> CMN: Sounds like we are on the same page - all we need to now is a lot of Work...
WAPA
<JF> scribe: JF
Cynthiadoing a demo of WAPA that she previewed at CSUN
<chaals> The demo we're looking at
cynthia has a slide deck of the demo as well, which she will post somewhere and share URL
<chaals> [Demo - a list where the ul element has an onariarequest handler (specific script written). There is no aria stuff inside the list items until you make an
aria request, and then the handler is called to populate the list with more aria attributes]
<chaals> another demoâŠ
<chaals> CS: On the checkbox demo, the handler gets an event type e.g. checking a checkbox
<chaals> s/scribe:JF/scribe: chaals
<chaals> ⊠the value is that you only add the aria when someone looks for it, which does good things for performance because moving strings around in the DOM is
expensive.
<chaals> ⊠you can switch state on e.g. select or toggle, instead of having to do event propogation etc.
<chaals> RS: A device-independent interation model would allow doing this kind of thing.
<chaals> ⊠What if you have a spreadsheet and cells -the container normally manages the commands.
<chaals> CS: This bubbles- it'sa standard DOM event.
<chaals> ⊠it only gets created when there is a call from UIA.
<chaals> ⊠Example: HTML etc - you get states and properties from a document but can't set them. What WAPA does is when the UIA layer calls for something you get an
ariaRequest event and you can react to it.
<chaals> ⊠has an event object, a typeâŠ
<chaals> CMN: motivators? performance?
<chaals> CS: Yes, and keeping track of state stored outside the DOM - e.g. somewhere in a script object ...
<chaals> ⊠Getting states and properties with better performance, and reacting to actions. Insteadof setting checked or aria-checked or whatever, the action it
"toggle" and you want it to work everywhere.
<chaals> RS: Look at a slider. You need to know something about it to know how much you advance it. There are things the author needs to support in the design
pattern.
<chaals> CMN: Does this have different interation whether you're working through AT layer or standard interface?
<chaals> CS: No, the idea is actually to unify them - you shouldn't care whether you have something defined in ARIA, or a natively toggleable thing.
<chaals> RS: You don't need a handler for the input type.
<chaals> CS: request to toggle would come in and do whatever needs to be done - more opions for interaction than just click.
<chaals> RS: Let's take a slider - there is a range. max/min/value and maybe a localised text version.
<chaals> ⊠might need increment, but to advance the slider you need to get the other stuff handled by the author. Or the interaction model won't work.
<chaals> ⊠In ARIA the author has to maintain a certain set of properties.
<chaals> CS: Actions for a slider are increase or decrease...
<chaals> RS: How do you know when you hit the max value?
<chaals> CS: whether it's an aria-created slider or an html range, you don't care. You can get them out of each type.
<chaals> RS: you have increment, decrement, maybe "bigincrement" - what if you slide it by grabbing?
<chaals> CS: Haven't thought through the details carefully, but anything in UIA can be hooked up.
<chaals> RS: OK. Yeah, the more involved kind of widgets take longer to deal withâŠ
<chaals> CS: Would expect to borrow a bunch of stuff from IndieUI - there's a lot of good thinking although I don't love the syntax.
<chaals> RS: We just want something devs can useâŠ
<chaals> ⊠would be nice if we could do this.
<chaals> ⊠do you want to be able to ad parameters to actions?
<chaals> CS: We're not at that level of detail yet.
<chaals> ⊠We're mirroring what we already have in UIA - the driving use case is that web apps can get the same richness of input that you have on desktop.
<chaals> [Demo: a checkbox. call the toggle action]
<chaals> CS: MSAA has "defaultAction" - UIA has a number of actions you can perform on things
<chaals> RS: To get this moving, open source code helps⊠can this layer be open-sourced?
<chaals> CS: Not a question I can obviously answer for the bit I have here, but UIA is an open spec, so it is possible to build an open source versionâŠ
<chaals> ⊠and we're interested in working with people, there is just an admin discussion about exactly what the process is âŠ
<chaals> ⊠back to toggle demo. we added commandName attribute to the event. But this is just a experimental syntax.
<chaals> ⊠some of this is based on the editing things being done in webapps.
<chaals> ⊠command event comes in from UIA, the name is toggle,
<chaals> JF: Is there a fixed list of commandnames?
<chaals> CS: think so, but there's no reason it has to be.
<chaals> CS: I have a single command handler, instead of having one for keyboard, one for touch, one for the other keyboard, etc⊠This is the big benefit which is
like IndieUI's concept.
<chaals> ⊠This seems simpler than the two-step process in indieUI. This script is simpleâŠ
<chaals> the documentation...
<chaals> CS: We just took the stuff we currently have as UIA event types.
<LJWatson> -
<chaals> RS: So percentage of scroll comes from where?
<chaals> CS: It's from UIA
<chaals> RS: Who sets it?
<chaals> CS: Whatever is controlling the UIA. Might be touch, âŠ
<chaals> RS: Page author has to be aware of this?
<chaals> CS: Yes.
<chaals> ⊠don't need to be attributes, you can hold them in script. Page author could react to a call for scroll percentage if they wantâŠ
<chaals> RS; Do you expect the controlling applicaiton to do a get of scrollPercentage?
<chaals> CS: DunnoâŠ
<chaals> ⊠looks like we have inbound events at the moment, but this isn't about them.
<chaals> RS: We have ARIA stuff that gets out of DOM into accessAPIs.
<chaals> ⊠we can set it and don't have to mess around.
<chaals> CS: THInk we are getting ahead of ourselves - if we decide to work on this we do need to look at those questions.
<chaals> RS: Just trying to understand what is expected.
<chaals> ⊠More we can pass off to the browser to do, the better.
<chaals> CS: There is the scenario of pass it to the browser, but we also need to handle the ones where authors *want* to control and handle everything.
<chaals> [CMN +1 to Cyns' seecond scenarion being another important use case]
<chaals> RS: There are accessibility people just wanting simple stuff
<chaals> CS: Right, but the goal of this is to extend what we can do, supporting advanced developers being able to do complex stuff their way. Hopefully getting this
right will enable some of the interesting things to be done more easily - but that's what we'll find out when we get a bunch of people sitting down to make it.
<chaals> RS: OK. We have to get this across platform⊠that will take a bunch of time.
<chaals> CS: NB my demos won't work except in developing IE stuffâŠ
<chaals> JF: Would like to send this to a dev in Amaze, and I can see them being excited by this.
<chaals> CS: Where that came up for us was listview JS controls. Maintaining aria state on those is really painful, and that's what motivated this.
<chaals> ⊠if you don't own a browser, there isn't really a good solution you can build...
Testing
<chaals> RS: Test cases are simple. If we can write a suite and run it automatically via Web Driver, with enough time - AT's might not respond fast enough for a test
case if you get it wrong - those are the things we need to worry about.
<chaals> ⊠Then we need to test the API for a pattern. Not sure how this worksâŠ
<chaals> CS: So far, it doesn't. We want further commands in web driver specific for accessibility apis.
<chaals> RS: So a common API would help hereâŠ
<chaals> CS: There's a hack for now - there are only a few APIsâŠ
<chaals> JD: We have a problem with webkit tests, wound up with a bit of code that took a role or property, and mapped it programmatically.
<chaals> ⊠the tests themsles don't know what the API is.
<chaals> ⊠The machine running the test knows what platform it is and where the results are - single set of tests, but different set of expectations for results⊠e.g.
testing ATK on WindowsâŠ
<chaals> CS: THe test has URL of a page, and an expected result. The HTML page has a test in it - just used Faulkner's tests.
<chaals> JD: Why need to query this?
<chaals> CS: testing that MSAA was actually implemented on a button - did it get into the accessibility API.
<chaals> JD: Did that for webkit tests, tool doesn't need to know the platform.
<chaals> CS: Testing that MSAA role == button which is maybe platform specific.
<chaals> JD: OK, understand - I didn't see the tests...
<chaals> LW: Hooked it to interactive tests yet?
<chaals> CS: No, but we picked web driver because it allows you to do that.
<cyns> <command sessionId="1" elementId="target"
<cyns> description="Verify MSAA name property for a button">
<cyns> <input>
<cyns> <![CDATA[
<cyns> {
<cyns> "name": "getAccessibilityProperty",
<cyns> "parameters": {
<cyns> "accApi":"MSAA",
<cyns> "id":"%ELEMENT_TOKEN%",
<cyns> "propertyName":"name",
<cyns> "childId":0
<cyns> },
<cyns> "sessionId": "%SESSION_TOKEN%"
<cyns> }
<cyns> ]]>
<cyns> </input>
<cyns> <response>
<cyns> <![CDATA[
<cyns> {
<cyns> "sessionId": "%SESSION_TOKEN%",
<cyns> "status": "success",
<cyns> "value": "Cyns Button of Doom"
<cyns> }
<cyns> ]]>
<cyns> </response>
<chaals> RS: When you get to stuff like accessible text interfaces that isn't so trivial. Roles, states, etc should be pretty reasonable. Why can't Shadi's team
contribute to the automated testing? There is something to be said for a 3rd party doing the testing - would be good if we can get that team to do itâŠ
<chaals> CS: Why not just web driver group?
<chaals> ⊠also want to talk about how brower testing and wcag testing don't fit.
<chaals> RS: Jon Gunderson does testing stuff. There are people who want to build common rulesets - Eric Velleman.
<chaals> CS: Webdriver doesn't currently support accessibility APIs. So you can't tell if e.g. a button ended up having the right MSAA role in the accessibility API.
<chaals> ⊠since it gets used a lot means that we could give a lot more acceessibility tests to people who are doing testing anywayâŠ
<chaals> ⊠if we could automate more WCAG testing, in this way, we could potentially get more people doing accessibility testing.
<chaals> ⊠testing web apps is different from crawling pages...
<chaals> JF: A lot of our application testing is pretty labour-intensive.
<chaals> ⊠automating testing is something we are interested in
<cyns> <BUTTON id="target" onclick="alert('you used me.. player')">Cyns Button of Doom</BUTTON>
<chaals> CS: Would love some help taking this to Web Driver group.
<chaals> [apropos of not much but related to keyboard focus navigation, a draft from Rich on SVG navigation now wikified in the SVG wiki:
https://www.w3.org/wiki/SVG_Accessibility/Navigation âŠ]
<chaals> CMN: So this is just a way to promote more people getting testing accessibility, with less pain so they'll get more of it done.
<chaals> ACTION cynthia to work with Léonie on describing the extensions requested to Web Driver, and the motivationâŠ
<trackbot> Created ACTION-318 - Work with léonie on describing the extensions requested to web driver, and the motivation⊠[on Cynthia Shelly - due 2015-04-23].
<chaals> we're back...
<chaals> going to poke into accesskey
Accesskey
<chaals> HTML a11y TF page on accesskey (part of the keyboard stuff)
<LJWatson> CMN: Accesskey is found on about 1% or 2% of pages.
<LJWatson> Fundamental problem is that browser implementations are broken.
<LJWatson> Behaviour is that this is a non-standard interactive element - not a form, not a link etc.
<LJWatson> Within an application you have functions you use many times - like "Mark as spam" in an email aplication.
<LJWatson> Shortcuts should not conflict with other things you use - like the browser or other UA.
<LJWatson> Accesskey only applies to elements on the page.
<LJWatson> CS: Overlap with IndieUI.
<LJWatson> CMN: Yes.
<LJWatson> Accesskey can work effectively - when you know they're there. No browser has a good mechanism for this.
(Where "this" = discoverability)
<LJWatson> In Opera we had an activation key, like the pass through key in a screen reader. It opened a menu showing the keys and the label for the thing the key
related to.
<LJWatson> It required accesskey mode, so no conflicts. Also problem where the shortcut wasn't available - on a different language keyboard for example.
<LJWatson> I built an extension. It put a button on the browser chrome.
<LJWatson> CS: Could use alt as modifier, because it mimics existin menu behaviour.
<LJWatson> CMN: The browser shold be the thing to decide what the mechanism for viewing accesskeys should be.
<LJWatson> Also needs to think about different interaction modes - speech, touch, keyboard etc.
<LJWatson> In the Opera extension you could define a list of accesskeys to be used.
<LJWatson> The browser sould take responsibility for the mapping.
<LJWatson> CMN: It's easy to determine what the available accesskeys are - but it would be easier if tied to a DOM attribute.
<LJWatson> Scripts would then have a message leaving system, so other scripts could find out which keys were already in use.
<LJWatson> CMN: Prefer this over access element because authors don't have to change their code/content.
<LJWatson> Also having a map that you impose over te page as part of the content is fragile.
<LJWatson> RS: Would be good to define certain types of elements - like this is the foreword, and have browsers define certain keys.
<LJWatson> CMN: Yes, for roles and landmarks - like screen readers do.
<LJWatson> CS: Think there are probably common application controls that should be managed in this way too.
<LJWatson> CMN: Yes.
<LJWatson> RS: Talking to Lisa on COGA. She wanted shortcuts for common content. Also for there to be a comon experience.
<LJWatson> CMN: Could use rel attrib.
<LJWatson> CS: Looking at INDIUI delete, pause, redo, undo etc.
<LJWatson> CMN: Where there are common controls, the browser should provide the shortcuts.
Summary of Action Items
[NEW] ACTION: Chaals look at the MSE and spliced advertising cases in particular 05/01/2015 [recorded in http://www.w3.org/2015/04/16-html-a11y-irc]
[NEW] ACTION: JF adding explanations of what transcripts might be 05/01/2015 [recorded in http://www.w3.org/2015/04/16-html-a11y-irc]
[NEW] ACTION: JF revising the transcript proposal from yesterday due 05/01/2015 [recorded in http://www.w3.org/2015/04/16-html-a11y-irc]
[NEW] ACTION: JF show how to use the proposal to meet various use cases 05/01/2015 [recorded in http://www.w3.org/2015/04/16-html-a11y-irc]
Summary of Resolutions
[End of minutes]
_________________________________________________________________________________________________________________________________________________________________
Scribes: Rich, chaals, JF
Present: JF RichS Léonie Cynthia Janina Joanmarie_Diggs
People with action items: chaals how jf show
--
Janina Sajka, Phone: +1.443.300.2200
sip:janina@asterisk.rednote.net
Email: janina@rednote.net
Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org
The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf
Indie UI http://www.w3.org/WAI/IndieUI/
Received on Tuesday, 21 April 2015 19:17:30 UTC