SV_MEETING_TITLE -- 08 Jul 2015

agenda bashing

<chaals> http://www.w3.org/WAI/PF/HTML/wiki/Meetings/HAT2015-zaragoza

read-only

<chaals> scribe: chaals

JD: We didn't have aria-readonly for e.g. checkboxes, radio, etc. But you have those things, so we should.

… made the change. But what about spin buttons, sliders, etc?

… Bringing back the panel thing, I came up with use cases…

-> https://rawgit.com/w3c/aria/zaragoza/aria/aria.html#aria-readonly what Joanie did

… I drafted some changes.

<SteveF_> readonly HTML5 http://www.w3.org/TR/html5/forms.html#attr-input-readonly

[use cases that make sense for this]

SF: In HTML5 the readonly is limited to stopping editing - input, textarea. contenteditable?

… we could look at broadening HTML readonly which I think is harder. Or unlink aria's 1:1 mapping

JD: Would lean toward the latter

… coupling only makes sense with the restriction on inputs - HTML5 doesn't apply to other stuff.

CMN: The use cases don't seem to me different for people using ARIA and the rest of the world [note the pointer to discussing ARIA itself later]. So maybe HTML is the right place to change - it doesn't even handle contenteditable, does it?

JD: ARIA already handles support for checkboxes in the current drafts. So we already started to diverge…

SF: What would it mean to have read-only for users in general. Nearest thing I can think of was when we had the inert attribute - you couldn't copy content. is that what we want?

JD: If you do, use aria-disabled.

SF: What would happen if this were HTML?

CMN: You would have things that are generally interactive, and take away their interactivity

SF: You can use disabled for that.

LJW: What about custom elements? Contenteditable?

JD: HTML and ARIA are aligned so far… except HTML claims it would not make sense for checkboxes or buttons to be read-only

… There are examples of people doing this, though.

SF: Think I have some tests with read-only on other stuff…

CMN: Pretty sure there are clear use cases for extending readonly

… so we probably should file a bug on HTML

JD: For aria-roles mapping to elements, keeping the things aligned makes sense. But you can turn a div into a file browser. So ARIA should extend the roles to which the property applies.

… see EDitor's note in my draft:

<SteveF> notes that current html def of readonly seems to limiting as it does not allow input type number/date etc

LJW: What difference does it have if you can't edit or if interactivity is irrelevant?

JD: For a normal input thing, the default value is false - you can change the value. Undefined means "there is no meaning for readonly". The use cases:

… 1. all input fields should be able to be readonly - e.g. checkboxes. Make sense?

LJW: No

JD: What if you have a checkbox?

LJW: Make disabled mean focusable, nothing to read

JD/SF: But there is state to read…

LJW: readonly has been for text content. Don't think reading a checkbox is applicable.

CMN: See use cases - e.g. a system setting that is a checkbox, but can't be changed until you do something else. You want to know that this is *potentially* changeable, but not right now.

LJW: Why do we need to let the user tab to it if they cannot read it?

JD: The ability to identify the value.

LJW: use disabled…

[discussion of whether you can find it…]

CMN: You should be able to use a normal navigation paradigm to find things that are at least sometimes interactive and have state you want to know, but you need to understand that you can't interact with it right now.

LJW: If disabled meant that, it would do this and be an improvement...

CMN: Could be…

… why does disabled make things unfocausable

<SteveF_> realted html5 bug Readonly attribute on input.{color|range|checkbox|radio} https://www.w3.org/Bugs/Public/show_bug.cgi?id=13390

… makes no sense to me that disabling the interactivity of an element changes how you can navigate to and read it.

JD: What if controls are disabled because they are dependent on the value of another control - can't you skip the whole set of controls then?

… Can we know that a disabled control will be populated with a valid value? Maybe doing it doesn't make sense.

… If there is a checkbox I can't change, I want to read the value, know it is valid. If there isn't a valid value, until it is enabled, bad things will happen.

… So think readonly and disabled are different for a reason.

CMN: Seems reasonably likely that authors ahve relied on disabled not allowing focus, so changing that would mess with deployed interaction patterns in bad ways

<SteveF> :read-write should always apply to input elements if @readonly doesn't apply

<SteveF> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15428

<joanie> https://stackoverflow.com/questions/12267242/how-can-i-make-a-checkbox-readonly-not-disabled

[looking at bug 13390]

JD: People are *doing* this in the wild, despite Hixie claiming it is bad UI.

<SteveF> http://www.w3.org/TR/html4/interact/forms.html#adef-readonly

JD: from the stackoverflow approaches, you get all kinds of approaches that will confuse the heck out of users who don't know why the checkbox isn't working.

CMN: Seems like there are real use cases, and that Hixie is just wrong in hi assertion that this should be banned.

SF: Something disabled isn't submitted. You might want something that is going to be submitted but can't be changed

CMN… yes, and you want the user to see that is the case.

<SteveF> custom checkbox with readonly and disabled states http://semantic-ui.com/modules/checkbox.html

CMN: Reopened 13390, but that doesn't answer the question at hand which is whether there should be an undefined state of readonly

JD: adding it doesn't change what false means, we're just going to add it to things that are not actual inputs, like panels.

… which is safe, we're not going to break anything.

… If we want to solve things like the file sorter case, I think we need undefined.

<scribe> ACTION: chaals fix bug 13390 when HTML is editable again [recorded in http://www.w3.org/2015/07/08-html-a11y-minutes.html#action01]

<trackbot> Created ACTION-328 - Fix bug 13390 when html is editable again [on Charles McCathie Nevile - due 2015-07-15].

action-328 due in 2 months

<trackbot> Set action-328 Fix bug 13390 when html is editable again due date to 2015-09-08.

<joanie> https://rawgit.com/w3c/aria/master/aria/aria.html#aria-readonly

[CMN asks dumb questions to understand how aria-readonly works right now]

JD: In aria, progress bars are said to have an implicit readonly=true, but that isn't carried through the spec.

CMN: Don't see that changing the defintion of readonly=false can break anything. It would require someone having implemented a way where making a paragraph aria-readonly=false suddenyl be editable, which seems unlikely

JD: There is a mess of inheritance in the spec, which makes this painful… if input inherits readonly then we inherit the ability for a single radio button to be readonly which makes no sense.

CMN: What if you make input things readonly=false, other stuff is readonly=true *by default* - unless you added some interactivity to it, you can declare that they're readonly=false

JD: If you have an image, a screenreader won't bother explaining that it is readonly, because that's just excess information

SF: A lot of elements in windows accessibility API does expose elements as readonly. I think that is a general thing - will have a look.

CMN: maybe only a theory issue, but if you default things to readonly, and then someone makes one of them interactive, without defining that it is readonly=false, will people be set up for a surprise because it changes when they do something?

… think that depends on whether you have a modal shift in interaction depending on whether something is readonly

[poking into the depths of this possibility]

JD: Going to make a draft that says readonly applies to more kinds of controls. Won't add undefined, nor the definition of false…

[break]

aria removable?

JD: I looked at the panel stuff from Léonie/Brian, and saw the "removable" thing, with an issue of what it maps to.

… seems there might be a reason to have something new for things that can be deleted - the same thing happens for files in a shared storage space, for example.

-> https://rawgit.com/w3c/aria/zaragoza/aria/aria.html#aria-removable Joanie's draft proposal

JD: Does it make sense to be able to remove things using aria-removable?

LJW: Think so

SF: What's the difference between dismissing a dialog and indicating that a thing is removable

JD: If I get a dialog I already know I can get it to go away. But if I get a site-specific notification about cookies, I want to know that they can be sent away.

… lots of things might be removable but it isn't obvious.

SF: Do we need aria-removable if we have close buttons?

LJW: that's like not using aria-invalid to show an error.

SF: You need to provide an activatable control to get rid of things.

JD: We still have cases where you can delete things in a collection…

SF: what about a role of dismiss for a button?

LJW: Where does the dismiss go?

SF: There is a button.

JD: You have a property that says "this thing can be removed…somehow…"

SF/LJW: You need an associated action, no?

JD: we need to have a binding - but what do we do where there is a button?

SF: Is there a difference between closing, and removing?

CMN: Maybe...

JD: WHy does panel have "removable"?

LJW: So we can create the panel with a dismiss control.

JD: SO do we want a removable?

SF: Can see why it would be useful, but not sure at this stage.

… can see it on a dialog…

JD: That's not a good thing to have

LJW: Not sure it is a problem…

SF: Think it needs more thought…

JD: It seems like the answer for the panel question is removable is not mapped to aria. Let's give this more thought sometime.
... aria-expanded is currently true/false/undefined - the last one means it can't be expanded or collapsed. So in the panel spec, map to aria-expanded

LJW: no, because its an indication in panels - and there is some disagreement on that at the moment.

JD: For panel, there is "expandable". Oh, so that doesn't map neatly…

LJW: Yes, there is a mismatch in the semantics of how we express them.

transcripts and aria

CMN: Anything to see here?

-> http://w3c.github.io/html-transcript/html-transcript-src.html transcripts draft

CMN: Quick overview - there is a transcript element that is meant to be a container for an actual transcript.

… and then we want one way to link transcripts. RIght now we have at least 4 too many proposed in the draft.

… There is a particular use case of using the transcript as a navigation device - search a point in the transcript, and the video / audio moves to that point.

… How would you do this in aria?

… my guess is that it looks like using aria-controls. Or?

SF: think the most obvious choice for the proposals is to extend track.

JD: the aria-controls relationship works if you have a transcript in an element. But *how* does something control something else?

CMN: Yes. Engineering the "how" question here, based on transcript use case alone is "ambitious". Probably not what we should be trying to do here.

JD: What does ORCA do when it finds a transcript controlling a video, compared to some other set of things controlling them.

… knowing that something is a transcript, and having a container for that, is pretty important.

CMN: At this point the proposal has an explicit transcript element. SO you know it is a transcript from that…

SF: does a transcript have timing information or not?

CMN: It may or may not, in the current proposal

SF: are we asking for a browser UI to meet this use case?

CMN: No, we just want to make sure it works when people implement it in JS in a webapp…
... the point of the discussion is to figure out if there is anything obvious where we might need to make new aria, or does it seem roughly like we can just figure out how to link the transcripts and use the web to make it accessible

SF: What is the state of the argument?

LJW: The argument that transcript isn't timed, which this version covers.

CMN: I think there were a bunch of proposals that hand't really been fleshed out in detail. This draft tries to do that (it is better for things I like more than things I don't, I suppose), which clarifies some issues of what is required. The baseline functionality is fairly simple, so it is a question of taste to some extent, but now we have something reasonable for people to look at and figure out what might make sense to implement, or not…

SF: Seems like the track option is a no-brainer…

CMN: video that changes in mid-stream, e.g. because you insert advertisements, or interactive video, etc...

JD: If you are adding things inside a transcript, we definitely want to know what is a transcript.

… also applies to magnification.

[lunch…]

date pickers

CMN: Date pickers… argh.

Making aria play with the rest of the children

<SteveF_> https://lists.w3.org/Archives/Public/public-html/2015May/0038.html Making ARIA and native HTML play better together

<LJWatson> scribenick: LJWatson

CMN: ARIA is not useful to most people. It was developed to be put everywhere, but developers have to provide all the interactions themselves - that has not been a success.
... Can we fix that?
... In Steve's email there are three suggestions.

1. When a role is used that matches the default implicit semantics of

labelable HTML elements [1] use of the label element will result in the

same behaviour as the native element and a <label>.

2. roles that match the default implicit semantics of interactive elements

are focusable (without need to explicitly set tabindex)

3. roles that match the default implicit semantics of interactive elements

[2] inherit the interaction behaviour of the native elements

SF: The suggestions received a lukewarm response at the time.
... One objection is that it would break backwards compatibility.

JD: Could there be an "opt in" property, that could be set?

<chaals> LJW: what would break?

LW: What sort of thing would break.

SF: If you had an element with event handling and a particular role, then had the browser provide event handling based on the role, it could break.

CMN: You could test by taking an ARIA button and apply its JS to an actual button, to find out whether anything broke.
... Is it a good idea to do ARIA outside of the accessibility API?

SF: Although the idea has been that it shouldn't, the spec language is very "airy fairy".

CMN: We want some better level of interoperability.
... Part of the question is how much of the objection (effecting native interaction) is because it would break the accessibility encapsulation?
... Related question is Web Components. If you're extending something, how do you add to or alter it's behaviour?

JD: Example?

CMN: Want to extend date pickers, so I can have a circular thing with the moon moving around. The interaction is the moon moving around the UI.

SF: The current date picker is shown by default. There are no separate modules.

CMN: Yes. If you use <input type="date"> that's what you get. No ability to choose to use my own "moon date picker" instead.

JD: <video> and <audio> have the controls attribute, which lets them decide whether to use the default browser UI. Could we use that model?

CMN: Yes, with the date picker that could be possible.
... Thinking about it another way... people make tab sets with ARIA. If we make a native tabs component, what's the process?
... Other examples, sliders, spinners.

SF: There are some reasonably good examples of custom sliders using CSS and bits and pieces - using <input type="range"> but putting stuff on top to make it look the way you want.

CMN: So hiding the original range, and layering an alternative view over the top?

SF: Yes, but you can still use the same interactions/keys etc.

<chaals> LJW: Do we know more about the proposal in ARIA2 to make ARIA extensible to cope with e.g. web components

<chaals> … think it is like windows control patterns

<chaals> JD: I think we are waiting on Cynthia to have time to move that forward.

<SteveF> input type=range examples http://codepen.io/collection/DgYaMj/

LW: We should start documenting use cases for extending ARIA capability beyond the accessibility APIs.

CMN: Yes. Some are obvious - like people who don't get the visual metaphor of what's on-screen, but don't have another tool to tell them.

rrsagent make minutes

JD: We don't know what developers are doing. If we could find an opt in mechanism, it would save a lot of testing.

SF: One of the suggestions in my email was to leverage the <label> element. Don't think this should break anything.

CMN: We should spend time today testing a few things out.

JD: Taking the first example in Steve's email (using the label element). If I've already provided that behaviour, there could be a conflict between the browser handling and the developer handling.

SF: The label example is fairly simple, in that it just binds a synthetic click event to the control.
... For the most part people dn't use labels on custom controls.

JD: But what if I did? People have to be able to opt in.

SF: Think we need to look at actual usage in the wild to gauge impact.
... If it breaks one site in a million, it's acceptable, if it breaks a thousand you have to stop and consider.

rrsagent make minutes

CMN: With opt in, you need al browsers to implement before anyone will use it.
... Once you get some browser implementation, it makes sense for others to folow.
... We want some examples from the wild and test to see if they break.

JD: How do we test?

CMN: Replace the custom control with its native counterpart and see whether the native event handling breaks the developer implemented event handling etc.

<chaals> https://yandex.com/yandsearch?text=aria%20examples

CMN: Do we have a good source of examples in the wild?
... The MDN examples perhaps?

<chaals> Random example 1 - http://oaa-accessibility.org/examplep/button1/ - just changing the li to button seems to break. But I didn't yet look at the JS to see if it depends on the thing being an li…

http://govuk-elements.herokuapp.com/

LW: Design patterns used on Gov.UK. Should include ARIA enabled patterns.

<chaals> Making the minimal required changes to my random example above, I don't see instant breakage… I'll post it somewhere people can test.

CMN: It passes the "sniff test". At least a basic example of a custom control from the wild that doesn't seem to break when native event handling is added.

JD: I think that implementing native behaviour when, for example, role="button" is used, would involve a huge amount of browser code rewrite.
... Then there is the question of performance - all the checks to determine whether the div actually was a div.

CMN: It isn't a trivial change.
... We should ask people who do browser engine core for their opinion.
... Why would you check eery div?

JD: When there is an event, it's sent to web core, then its processed to see what kind of event it is, then what it should cause to happen.

CMN: Essentially the proposal is that whenever you find something with a role on it, then you push it down the path of the element corresponding to the aria role, rather than the default role for the element.

JD: Could do an implementation example for firefox perhaps.

SF: Are we approaching the problem in the wrong way? for the majority of simple widgets (buttons, checkboxes etc.) with native equivalents, is because of the styling problem.
... Do we need to improve the stylability/usefulness of the native implementations?
... Same for simple Web Comps.

JD: A point made earlier was that developers don't get the scripting part right.
... So the problem and the solution are in the JavaScript.
... What is falling apart is the JS for accessibility. If we can fix things there, that would make sense.

<SteveF> What ARIA does not do http://www.paciellogroup.com/blog/2014/08/what-aria-does-not-do/

LW: I've spoke to a lot of developers who initially assumed that ARIA would provide functionality.

JD: Did they nt notice when it didn't work?

LW: Yes, but this is the way developers think ARIA shold work, before they discover that it doesn't.

CMN: When you have a real button and you hit the enter key, it generates a click event.
... They won't generate click events for custom buttons.
... So I provide a click handler for a <button> and it can also be used with the keyboard. If I create a custom button the keyboard handling has to be added by the developer... and that equals death.

JD: If we leave it to authors to handle the user-interaction, they get it wrong. But it works for mouse interaction, so where does it go wrong?

CMN: In providing the keyboard interaction.

JD: Are there others?

LW: Touch opens up a world of problems for accessible event handling.

CMN: I suspect that things are not rosy in voice/speech recognition - but not sure.
... So problem #1 is author provided interaction.

JD: Trying to zero in on the problem. Is it just event handling? Tabindex causes things to become focusable.

LW: If you use <button> and provide click handling, the browser throws in keyboard handling for free. If you use a custom control that doesn't happen.

JD: Other examples?

SF: A native link is activated by enter, and space scrolls the page.
... Perhaps checkboxes too?

JD: Is it just handling space/enter on controls with tabindex?

CMN: There are considerations with other things like sliders, tabs, date pickers etc.
... Also thinking about the "where am I?" problem.
... Does HTML define what happens when you click on something?
... Two things that are failing are - orientation information, and author defined interaction.

LW: You'r eincluding the problem with people not understanding the visual metaphor, within the orientation issue?

CMN: Yes. Also live regions. If you have a live region not in view, how do you know the thing changed?
... Browsers decided that wasn't important.

JD: My cconcern is that different users have different ideas about what it is they need.
... Leaving some of that to the AT gets us a bit closer to meeting people's various needs.

CMN: On the CMN: On the other hand there's nothing worse than missing information.

JD: Yes, but I'm not sure it should be down to the browser to provide the behaviour?
... Can you use CSS to inject elements?
... Can you use CSS to inject elements?

CMN: No, images and text.

LW: CSS generated content is available in the acc APIs in all browsers except IE.

JD: Wondering if something has tabindex...

CMN: If something has a tabindex it should be interactive. The difficult part is knowing that that interaction should be.

JD: Could we then have an attribute that will cause space/enter to work - not even an ARIA attribute?

CMN: Would say that's unlikely.
... Perhaps we start with browser bugs?

JD: If it's a native button element and you press enter or space, the browser generates the click event? so we need some attrib like handleonclick or something.

CMN: You don't want an attribute for that. You just want browsers to do it.
... There is a problem case when a user expects space to scroll the page and not activate a link, or vice versa. Then we get a bad UX.
... Asking developers to fix this means we'll have a problem forever.
... The real problem cases are where there is special handling. A slider and space pushes the slider to the end, where as click does something different.

JD: How could that be solved?
... What is the keyboard interaction we'd expect?
... Like tabindex - it works, but it isn't connected to ARIA.

LW: ARIA expanded the capabilities of tabindex to include 0 and -1 values, so it is sort of connected.

JD: Was thinking more about aria- attributes.

<chaals> [[[

CMN reads from UIEvents.

CMN: What is it about button that makes it get the click + keyboard handling?

JD: It starts at the platform layer and bubbles up to web core.
... Thinking out loud, seems the problem is when the host language hasn't defined it, and the author has to provide the mechanics.
... When what we want is for the author just to provide the activation trigger.

<chaals> [noodling on the problem that when you make <button onclick="foo()"> you can use a keyboard activation and the browser runs foo(). But when you have role="button" onclick="foo()", that doesn't happen.

LW: This is where we arrive at IndieUI isn't it?

JD: I wondered about that.

CMN: What we want, is where you have a role that points to a known element type, we want the same activation behaviour to be provided by the browser as it would for the native equivalent.

JD: What if there was an activation behaviour attribute?
... If we had a new attribute, let's say treat-like. So <div role="button" treatLike="button">?

CMN: It would give us element behaviour.

LW: Feels like is= again many respects.

JD: is=?

CMN: Web Components syntax for implementing type extensions - where you inherit the characteristics of a native HTML element.

JD: Could a new attribute solve this?

CMN: It could work, probably.
... Question is it necessary?
... If you have role="button" you should get the default interaction for button.

SF: Plus other events like touch.

CMN: Yes. Would it break anything? Probably not.

JD: I still think it might break things. I think an extra attribute is a better thing to sell.

CMN: Selling an extra attribute isn't easy - the key to what we want is that authors doing the naive dumb thing actually get the outcome they would like.

LW: It will be met with the same objections as is=.

JD: Don't think people will be happy about the potential for things to change.

CMN: The risk scenario is that the author assumed that the browser would provide native interaction, and it doesn't. Providing that native handling wouldn't break that.
... Even when an author has provided custom handling, it still wouldn't reak.

LW: It'll work in the same way it does now if you put custom handling on a native element - the browser handling is overriden by the custom handling.

<SteveF> http://www.paciellogroup.com/blog/2015/07/a11y-slackers/

<joanie> https://trac.webkit.org/browser/trunk/Source/WebCore/html/RangeInputType.cpp#L194

<chaals> slider examples

Wishlist

<chaals> the TF wishlist

<chaals> work statement

CMN: We have keyboard interaction on the wishlist. Trying to identify problems with the current interaction models, and what we might be able to do to fix them.
... There is transcript. We now have a prposed spec.
... Panels and panelsets. There is a spec for this.
... There are date pickers. https://www.w3.org/WAI/PF/HTML/wiki/Datepickers
... Menus. Cynthia might be interested possibly.
... Payments. Shane is assigned to this.
... On the list of things without owners there is referencing UAAG, footnotes, cognitive (being done elsewhere), media descriptions, numeric inputs, Emotion ML...

LW: Wouldn't mind looking at Emotion ML.
... What was the reason we wanted to look into it?

CMN: Don't know. Mark S was originally assigned.

LW: Will ping him.

CMN: Haptic feedback - Léonie, Marku and me are interested.

<janina> Shane, Theyre's a mini F2F ongoing in Spain. That's what you're seeing.

rssagent, set logs world-visible

CMN: Gaming.

LW: Any idea what aspect of gaming we wanted to look at?

CMN: No.
... Explore requirements for gaming.

LW: That seems beyond the scope of HTML.

CMN: Media descriptions - associating short or long textual descriptions.
... Think in media we have mechanisms for everything except transcripts, and that's coming son.
... Would like to take up media descriptions.

<chaals> ACTION: chaals to take up "media descriptions" topic in the TF [recorded in http://www.w3.org/2015/07/08-html-a11y-minutes.html#action02]

<trackbot> Created ACTION-329 - Take up "media descriptions" topic in the tf [on Charles McCathie Nevile - due 2015-07-16].

CMN: We should look at Canvas. Does it allow an alt?

LW: No, don't think so.

CMN: No, confirmed it doesn't.

<chaals> action 329?

<chaals> action-329?

<trackbot> action-329 -- Charles McCathie Nevile to Take up "media descriptions" topic in the tf -- due 2015-07-16 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/HTML/track/actions/329

CMN: New things... someone suggested zip codes.

Cognitive TF http://www.w3.org/WAI/PF/cognitive-a11y-tf/

CMN: Pause for weekly TF telecon.

Weekly teleconf

<chaals> chair: Chaals

<plh> scribe: plh

<chaals> scribe: chaals

canvas implementation - RichS, MarkS, where are we up to?

[see PLH's email]

PLH: wrote 3 of the missing tests, the fourth one I don't understand. need to sit down with Mark to work it out.

… updating results. For one new test there is a bug in chrome, not reporting the right region in accessibility API, will double-check before filing bug.

… If we're lucky, Mark and I will meet to make progress this arvo. Else Monday.

<plh> canvas update

CMN: You expect hitregions will make it?

PLH: Hope so. If we have an implementation with a recognised bug expected to be fixed, we should be able to move forward with it.

face to face meeting - what are we doing / what did we do?

<plh> scribe: plh

Charles: only 3 or 4 of us were able to attend
... looking at keyboard a11y for ARIA
... and Joanie is helping in our understanding of the webkit code

(see minutes at http://www.w3.org/2015/07/08-html-a11y-minutes.html)

Charles: questions about the f2f?

[none heard]

editing the alt guidance https://github.com/w3c/alt-techniques

Charles: any news from Shane?
... we have a github repo. PR to gh-pages branch?

Shane: go for it

transcripts: call for First Public Working Draft? w3c.github.io/html-transcript/html-transcript-src.html

Charles: [under discussion at the f2f]
... we'll continue to propose a FPWD
... PRs are welcome

action item review https://www.w3.org/WAI/PF/HTML/track/actions/open

[going through the actions]

Charles will chase the tab panel through the WICG

action-260?

<trackbot> action-260 -- Shane McCarron to Present web payments in tf meeting -- due 2015-06-30 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/HTML/track/actions/260

Shane: make it 3 weeks from today

<chaals> action-260 due in 3 weeks

<trackbot> Set action-260 Present web payments in tf meeting due date to 2015-07-30.

<chaals> ACTION: JF get the matrix to Shane… [recorded in http://www.w3.org/2015/07/08-html-a11y-minutes.html#action03]

<trackbot> Created ACTION-330 - Get the matrix to shane… [on John Foliot - due 2015-07-16].

<chaals> action-327 due in 1 week

<trackbot> Set action-327 Check if chrome hitregion implementation actually works due date to 2015-07-16.

<chaals> close action-317

<trackbot> Closed action-317.

Charles: we've been looking at readonly for forms
... we think it make sens to have readonly for checkboxes, textinput, etc.
... we see people trying to do so
... idea is to make them unfocusable

Editing the HTML spec

<chaals> scribe: chaals

<plh> https://github.com/w3c/spork/blob/master/README.md

PLH: spent yesterday doing things in the HTML spec, so here is how to do it.

Start at spork's readme - that's the tool that converts the WHATWG spec to HTML 5.1

… change spork, it generates the spec.

… If we manage to make progress on modularisation, the story may change entirely.

… if we make modules, people will be able to make changes that will be propogated from spork.

<plh> https://github.com/w3c/spork/pulls?q=is%3Apr+is%3Aclosed

… Start with the readme, edit a clone. Spork applies JS rules to the spec. In the editing section it tells you what has to be changed- we have examples, as above.

… Depending on the type of change you make, e.g. touching something we are modifying, you have to find which rule is applying by grep for a keyword.

… If you modify something we haven't touched from WHATWG, you make the rules - we have examples of that too.

… Yesterday I modified an algorithm, and fixed a typo.

<paulc> Are your changes tracked in a Bugzilla bug?

… So I encourage you to look into that. It is a little painful, you have to use jquery. Takes a bit of getting used to.

… But then goes faster. If you have trouble, I'm happy to help you.

<SteveF> plh: sounds painful ;-)

… But I hope that now I have cleaned up documentation, it should be easier.

s/plh: sounds painful ;)//

PLH: Yes, changes have bugzilla references in them.

<paulc> Thanks

PLH: Not painful - takes understanding but isn't that complicated.

CMN: If there is a change that is a bit controversial, what is the process?

PC: Make the change, send a note to public-html.

… when editors were cherrypicking WHATWG changes, they sent patch notices - bug number, what they did. Seems a reasonable model to follow.

PLH: I did pull requests, Robin merged them.

… I didn't commit directly.

… If you have a change like that, make a PR and have the discussion in bugzilla/ public-html

PC: Seem to be in a middle ground here. Not many people would know that they should start tracking github for pull requests. We should aim to be transparent so people know what is going on.

PLH: I made Pull Requests…

… and Bugzilla changes

PC: Yes, but people don't see those unless they signed on to track the bug when it was created.

… so people won't know.

PLH: OK, for the substantive algorithm that was a substantive change matching implementation, it makes sense to send something.

PC: OK. We should encourage people to write to the WG about the Pull Requests, as a way of socialising how we are working and remind people where to look.

<plh> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=bug_id%2Cassigned_to%2Creporter%2Cbug_status%2Cresolution%2Cshort_desc%2Copendate%2Cchangeddate&component=HTML5%20spec&list_id=58112&order=opendate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=HTML%20WG&product=HTML.next&query_format=advanced

PC: there are fewer bugs - has there been a change?

PLH: Yes.

CMN: A bunch of people have been closing out invalid bugs…

PLH: There are bugs that will not generate changes in teh spec. I have been going through the easy ones to learn how to edit HTML.

<paulc> THANK YOU, plh

PC: Thank you PLH

PLH: Welcome :)

<JF_> +1 thanks PLH

[teleconf adjourned]

- DRAFT -

SV_MEETING_TITLE

08 Jul 2015

Attendees

Contents

agenda bashing

read-only

aria removable?

transcripts and aria

date pickers

Making aria play with the rest of the children

Wishlist

Weekly teleconf

canvas implementation - RichS, MarkS, where are we up to?

face to face meeting - what are we doing / what did we do?

editing the alt guidance https://github.com/w3c/alt-techniques

transcripts: call for First Public Working Draft? w3c.github.io/html-transcript/html-transcript-src.html

action item review https://www.w3.org/WAI/PF/HTML/track/actions/open

Editing the HTML spec

Summary of Action Items

Scribe.perl diagnostic output