W3C

- DRAFT -

Protocols and Formats Working Group Teleconference
09 Feb 2015

See also: IRC log

Attendees

Present
Regrets
Leonie_Watson, Ann_Abbott
Chair
SV_MEETING_CHAIR
Scribe
jamesn

Contents


<trackbot> Date: 09 February 2015

<scribe> Meeting: ARIA Authoring Practices TF

<scribe> scribe: jamesn

Meeting Schedules

MK: Presidents Day next week

no one gets the day off

MK: we will meet next week
... Week of CSUN... March 1

JN: Prefer not to meet that week

tooltip http://www.w3.org/WAI/PF/aria-practices/#tooltip

<mattking> https://www.w3.org/WAI/PF/Group/track/actions/1574

ACTION-1574: Propose wording for a browser and assistive technology note for example pages

ACTION-1574?

<trackbot> ACTION-1574 -- Matthew King to Propose wording for a browser and assistive technology note for example pages -- due 2015-02-09 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1574

MK: The list is whatever the people who coded and reviewed the example used.
... There might be some we don't list on purpose.
... Just listing for people's reference. We are not making any other guarantees
... right now we are mostly looking at JAWS 16 and NVDA q4.2014

JG: Seems like a lot of noise
... Maybe the examples should stand on their own. Could get =confusing and distract from what we want is how people build the widget
... if we have a standard thing - but if we are letting someone decide what to list

MK: could guarantee plaforms but not versions

JN: perhaps we should say where it doesn't work in modern browser UA combinations

MK: potentially there is some difference.

<Birkir> What about a show/hide "assistive technology testing" section for each example. Offers possibilities to add, can be viwed if interested, but does not get in way of those who do not want to concentrate on taht.

JG: devs want some level of confidence that if they use a practice they will get some level of compatibility withj AT
... Is this part of the groups resopnsibility

All: no

<Birkir> Yes, 919 is me, just like 007 is Bond .. he is cooler but less interested in accessibility

<Birkir> I have once implemented a set of widgets, I had to make extensive notes on responsive behavior and a.t. compatibility, paritcularly voiceover as opposed to Windows, of course that was a client ask, but those notes turned out a lot more extensive than I ha anticipated

MK: if someone wants to learn what the people who wrote the example expected the experience to be - they could then reproduce exactly

LW: these just need to be examples of the design patterns

JG: Want to be clear what it is we are trying to do here
... Just want to be clear that if we are going to publish compatibility information why we are putting it in there
... have kind of a contract with people using the examples

LW: have to make it complrehensive to be useful
... if it just says JAWS16 and FF then how much practyiocal use id that in the real world

MK: think it is useful as it tells you that it wasn't written for jaws 3 or ff99.

LW: what good does it do in isolation

<janina> Isn't the purpose of W3C specs/notes to be agnostic about UAs and ATs?

Bryan: if it doesn't work in an AT / browser then it is the AT / browser fault that it doesn't work.

MK: then should put a date in there

Bryan: taking a forward looking approach then it is up to the AT to convey whether they support the use of aria

JN: shadi's work on database

<scribe> ACTION: James to talk to Shadi about the database to mark accessibility support of the examples with crowdourcing [recorded in http://www.w3.org/2015/02/09-aria-apg-minutes.html#action01]

<trackbot> 'James' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., jcraig, jhawkins2, jnurthen).

<scribe> ACTION: jnurthen to talk to Shadi about the database to mark accessibility support of the examples with crowdourcing [recorded in http://www.w3.org/2015/02/09-aria-apg-minutes.html#action02]

<trackbot> Created ACTION-1577 - Talk to shadi about the database to mark accessibility support of the examples with crowdourcing [on James Nurthen - due 2015-02-16].

examples - how to work with github

LW: make a fork of the aria repo

JG: can you turn a clone into a fork?

LW: don't believe you can

<Birkir> What I dream about, as a SME/user, would be to use these examples as test harness .. and report bugs to vendors of browsers/AT based on these examles, har to argue with them being best practice.

LW: take a copy and paste into the fork
... send a pull request back to the main aria repo

MK: does the fork end up in his own space

LW: a fork is your own local copy completely seperate then once comitted then you issue a pull request to the main repo
... the chanbges then get merged back into th main copy

JG: will try to get in a fork this week
... should have an internal standard that we should test things on A, B and C.....

MK: one of the things I am concerned about in general is if we were to document expected results then just to say code it like this and then run it with some AT or even no AT. People will experience something but the question is whether what they experience is what we expected.
... If we are relying on there being no bugs in the version they are using.

JN: how would you possibly document that?

MK: spinbutton for example
... trying to think how we could communicate this. for link and button maybe straightforward but for others maybe more complex

JG: could have pseudo code for like if move slider user should be made aware of new value

MK: if press down arrow and screen reader says nothing. Is that a bug? Does the person who experiecnces that for the fiorst time know that there is a bug

JG: should look a the authoring practices to see if there should be a place where we state what should happen on certain interactions
... what are we trying to do and what are we not trying to do
... going to be a lot of work for us. What developers want to know is how should I be using aria
... if s dev doesn't know how a screen reader works then our doc isn't going to be much use
... Should do the best to help developers use aria technology the best we can
... if we are doing something to get around limitations we should document it.

MK: have talked about our audience being devs and toolkit devs & also AT vendors being part of our audience too
... brand new 1.1 features - we need to help AT devs know how they are going to be used and what is the repsonsibility of AT
... we were going to put a note that something was a new feature and not yet properly supported by AT
... I think you are spot on Jon - need to decide what we are doing and why we are doing it

JG: it is not the job of this group
... think we need a minimum set of standards for this group
... some groups talk about current and last vcersions of AT

MK: we need to be developing code examples for (exmaple) aria-current with code samples where we can point the AT vendors to it.

JG: At vendors don't want to be told how to create a UI
... anything like that would be interpreted as beyond the scope of the group

Bryan: how would you know if there was a max value of 11.
... could put in the valuetext
... if you have a time slider the only way to convey AM and PM is to add it all to aria-valuetext

JG: not sure what the APG can do to help with that
... close to consensus. Don't want to talk about what AT should and should not so. Want to have some list of what we test against. question is if we include that information in the note

JN: agree with pretty much all of that

<janina> Log a resolution

<janina> Indeed!

RESOLUTION: We will not dictate AT behaviour.
... We want to test our examples with a core set of browser and AT combinations to be enumerated later
... Sometimes we may want to suggest outcomes that browsers and AT may want to ensure are communicated but without suggesting exactly how they do it.

proposed resolution: we will generally not document workarounds where the browser or AT is not following the standards correctly

RESOLUTION: we are looking for the current best thinking in aria development for what the features are meant to achieve.

discussion over a note to state that people are encouraged to use recent versions as stuff changes....

JS: reason stuff changes is that aria is in current active development

RESOLUTION: we will generally not document workarounds where the browser or AT is not following the standards correctly

Summary of Action Items

[NEW] ACTION: James to talk to Shadi about the database to mark accessibility support of the examples with crowdourcing [recorded in http://www.w3.org/2015/02/09-aria-apg-minutes.html#action01]
[NEW] ACTION: jnurthen to talk to Shadi about the database to mark accessibility support of the examples with crowdourcing [recorded in http://www.w3.org/2015/02/09-aria-apg-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/02/09 19:13:55 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: jamesn
Inferring ScribeNick: jamesn

WARNING: No "Present: ... " found!
Possibly Present: All Birkir Bryan Bryan_Garaventa IPcaller JG JN JS James_Nurthen Jemma Jon_Gunderson LW MK Matt_King P3 aaaa aabb bgaraventa1979 https inserted jaeun_ku janina jongund mattking trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Regrets: Leonie_Watson Ann_Abbott

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 09 Feb 2015
Guessing minutes URL: http://www.w3.org/2015/02/09-aria-apg-minutes.html
People with action items: james jnurthen

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]