See also: IRC log
<JF> scribe?
<scribe> scribeNick: jamesn
JS: Need to enumerate
concerns
... reading order, injected content
... Perhaps suggested a browser bug
... what else
MK: discussion of whether or not CSS has or should be interpreted as having any semantic meaning
I have noticed things if, for example, you put padding on an element. apple interprets it as space. Apple will read things as different elements if you space stuff out with padding
nobody else does that
would need to put spaces in to do that.
JN: to me looks like apple is doing some sort of heuristic repair
JD: to follow up what MK said. The spacing could be an apple issue. related to that multiple user agents are exposing css tables to a11y apis as tables
CS: order and position are
meaningful in many cases. so i like it
... w3c made a mistake seperating content from presentation
assuming presentation is not meaningful
... may be a bad implementation
MK: presentation has meaning but it is who is repsonsible fro presenting in the a11y layer
JF: in reviewing COGA proposal.
Lots has to do with content filtering
... seem display related - believe sits in the world of CSS
one example is an aria way of illustrating litteral and non litteral things. Ruby markup and CSS could be a way of doing that
JS: where css could resolve something which showed up in one of the TFs
JF: maybe should engage with CSS
JS: lets wait until the gap
analysis isx put together
... waiting for them to redo docs to remove aria from it
... think we can tell CSS folks that we will need to talk to
them
JW: still have issues around media queries. there is leftover business for media queries to specift individual needs and preferences. as well as issue regarding the kind of extensions which might be needed for coga for example
also have privacy issues around this
have a lagrge media queries issue
JS: have class of problems with CSS - and then a range of problems which are not problems but where we are looking for things from CSS where we would need to work jointly with them
JW: work underway in DPUB (joint css and dpub concern)
at least one known implementation of a braille stylesheet - allowing braille stylesheets development and what css support might be needed
coming from dpub - at that time css didn't have the grid layout necesary but i think that has changed
<contents of whiteboard>
Semantics of CSS - Layout
Reading Order / Tab Order
Injected Content (Meta: w3c issue? )
<fantasai> pointer to braille impl?
COGA Heads up
Media Queries - Usercontext
CSS Based Braille Style Sheets( ie E-Pub)
META: Problems, Opportunities
<fantasai> yes, but who develops it?
MK: reading order / tab order.
Need to get to a point so certain things happen in CSS as to
what swhould happen
... need to get our team all on the same page
JF: we do have tools to stand firm.
CS: need to stop doing that
MK: we need to know where we stand
JS: 1. it remains unresolved, 2. we have added yet another spec where it is an issue
CS: need to look for other solutions other than the DOM needs to be in the same order
<Zakim> MichaelC, you wanted to mention base font etc and to mention system colors and to mention generated content / cssom
<MichaelC> CSS issues on PF wiki
MC: base font. system colors.
desperate to see something like that come back
... connecting with user preferences
... the other one is the injected content issue
MK: need to figure out whose responsibility it is
MC: need to work on that
CS: on the order issues
... tables/grids etc into a11y api grid is an interesting
solution
... we have an interesting problem. a fundamental feature of
the architecture has a problem.
becuase of a quirk (and IMO a bug) the order in an AT is based on the DOM order
and the order of the mainstream experience is not. telling authors to ignore those features of CSS
<mhakkinen> +q
JN: firefox layout engine currently does drive the order for AT - I believe that is a good behaviour. But I believe the spec says that this isn't the correct behaviour
need a spec change to allow this and perhaps even require
ut also maybe need a way for an author to say the dom order is the correct order and not to do that
<cyns_> cs: we need to accept that the idea of authors must keep dom and layout in the same order is not going to work. we weren't effective doing this 10 years ago, and won't be now.
cs: we need to accept that the idea of authors must keep dom and layout in the same order is not going to work. we weren't effective doing this 10 years ago, and shouldn't be now.
JB: have done some DOM order and flexbox experiments. pretty close to having support for what we are doing in browsers. seems to me that efforts to influence the behaviour of ATs might not be necessary.
<Zakim> MichaelC, you wanted to identify meta-issue on semantics vs presentation
MC: content vs presentation
seperation. That concept is difficult as authors and devs talk
differently
... bigger issue than CSS
fantasai: seperation of content and style is important for maintainability and responsive designs
to do layout for all of these well you need media queries and to have a semantic based document.
MC: yet authors don't get it
fantasai: can't get layout to work unless my dom structure has all of this stuff in it
<fantasai> fantasai: so to get the things they understand (visual results) they're learning to make this distinction that we need for a11y
MK: so back to the FF defect
which was raised and echo JN that the behaviour was good not a
defect
... that should not be undone
... still have the issue of keyboard tab sequencing
https://bugzilla.mozilla.org/show_bug.cgi?id=812687
MK: I am of the opinion that keyboard order should follow layout not the dom order
the notion that it is ok to jump to the left/right sidebar etc. is a problem especially for those with a low field of view
the relationship between keyboard sequence and reading sequence is incredibly important
MK: should expect the logical order to be the same as the order with touch. I beleive wcag is too forgiving - doesn't adequately descrive meaningful seqauence
whether flexbox or float is irrelevant
needs to be a way for the reading order and keyboard order to match the visual order without needing the dom to be rearranged
hard to imagine scenarios where you override the default
fantasai: do users want to see the sidebar or the main content first
MK: the main question is what is the logical order
obviously some sitations where there are multiple blocks etc. but a well designed page only has a few tab stops per region
as you tab through the page i would argue that most of the time the left sidebar should come before
fantasai: often can put sidebar on the left or the right. that doesn't make a meaninful difference to a sighted user. If on the right want it to be after and if not before
MK: this is especially important for a screen maginifier user. If the content is in my reading order and if it moves to the right. have a banner and if the tab key jumps to the right side bar then back to the left then you have lost me
<kurosawa> TK: One thing we should remember is we have encoruaged usage of user stylesheets. So once CSS has semantics meaings, people who use user stylesheets can't understand the semantics. That is the bad thing.
TK: for DOM order etc. major
browsers provide spatial navigation moving focus by pressing a
nav key
... I disagree with making CSS having semantics
CS: I don't think framing as CSS having semantics is the right discussion
what can we do in the browser and AT layer to fix the problem
fantasai: if you want to navigate spatially then need to make things work for that before getting an auto layout thing to work
CS: touch screens - everything has the possibility.
fantasai: so many ways to reorder content that can't always fix things in 1 way
there are use cases for wanting the linear order to be the same as DOM order but others where not
picture above the heading
we would like for the author to put things in the right order - dont run into the keyboard order thing
we want the ability for the author to seperate the content order to be out of sync for the visual order they want
CS: something we haven't discussed much is that there is a difference of opinion as to what is better
MK: disagree that the example it is better to display things in wrong order. it is an unusual layout but depriving me of information is doing me a disservice. when touch is so prevalent. 2 ways to navigate in a touch screen reader.
if I swipe right after the picture it would then go to the next heading not the one in the next visual order. It is a problem
it skipped the next paragraph
fantasai: mixing navigation modes.
MK: always switch between them. It has to be natural
<MichaelC> scribe: MichaelC
js: @@
cs: need user reseach
fantasai: @@
cs: browser may need to enable both
mk: not asking for change of position, but information about relationship
<mhakkinen> +q
fantasai: could ask for order in either spatial or logical order
at user choice
jn: @@ navigating the grid
fantasai: you could have a grid layout with header in middle and grid surrounding it
you wouldn´t follow the screen order if I told you to read me the page
jn: there are other layouts where things land wherever there is space
fantasai: if there is no meaningful sequence
jn: don´t want tab sequence to be confusing
<Zakim> JF, you wanted to note taht I18n issues may create a situation where L-to-R sequence would be R-to-L for some...
jf: need to be flexible on LTR vs RTL
tk: HTML has dir attribute so we don't need to do that in CSS
jgw: needing to override with tabindex is complicated
<kurosawa> tk: dir doesn't affect reading order of screen reader
we should consider whether CSS is the place to address navigation sequence
<fantasai> [discussion mentioned that tabindex navigation is not great, and need an improvement to this; also mentioned flagging navigation points and possibly reordering them]
mh: IMS has presentations that should be well out of order from the visual layout
it´s non trivial
ms: screen reader users all have their preferred method to navigate
many still navigate by heading
can be confused if they move down from heading and wind up on content that´s not associated with it
js: sounds like CSS won´t solve everything
<mhakkinen> IMS uses term “inclusion order” which can define how “access elements … aka content blocks” are presented sequentially via read aloud tools.
we need to sort out what we think it should and should not
<Zakim> cyns_, you wanted to mention screen-reading for users with reading disabilities, but who can see. Visual layout is going to be important to these users.
cs: also need to consider visual users with reading disabilities
ms: that´s what we deal with
fantasai: if we could get authors to make source code order logical for reading, then re-arrange with CSS
you would have information about both the logical and the spatial order
which would make it easier to implement navigation supports
spatial, and sequential
need to not shoe-horn this all into one solution
<fantasai> I think it's important to distinguish between spatial and presentational -- speech is also a presentation!
<kurosawa> +1
<fantasai> What I was saying earlier is, it's been very interesting to hear from different people here about their navigation preferences.
<fantasai> I think the current architecture we have will allow UAs to provide all of these in a well-designed page.
<fantasai> And grid/flex layout will make it easier to implement
JB shows demo
discussion of authors do or don´t
MC realizes someone should start scribing and tries to catch up
js: we don´t like the guidance in the css flexbox spec regarding tab order
but CSSWG thinks it´s correct
we need to work with them on what we both think it should say
mk: @@ keyboard sequence dom order?
cs: lower priority
jn: exception case
mk: outlaw @@
@@ modify sequence
mk: mechanism to override default behavior
cs: navindex?
fanatasai: wasn´t supported, dropped
jn: @@
cs: and float
jw: css as mechanism for determing navigation points
need to discuss how
cs: not sure css should determine it
there should be an order that reflects what´s on the screen however it got there
jn: css might think warning in spec address a11y
but in reality if something is possible developers will do it
mk: don´t want to put authors in position where they can´t use css for accessible responsive design
jn: but they´ll do whatever they can
mk: limits reasonable use of css
fantasai: don´t think that´s a reasonable use
should order the dom
css is about creating visual interpretations of the doc
the dom is the core doc
mk: so that means visual presentation has no meaning?
fantasai: that´s the goal
mk: but it´s not true
positioning tells user how things relate
placement has meaning
fantasai: placement is a way to express meaning
as well as color, etc
mk: css is the way that is expressed
<fantasai> "green" isn't the meaning, "highlighted" is the meaning, "green" is a way to express it
mc: we´re back to misunderstanding that semantics and presentation are mixed
cs: presentation implies semantic sometimes
mk: if css is the tool...
fantasai: css expresses the association using presentational output
but under the covers you don´t have to guess at the semantics, they´re there
a fully presentational approach would be sending images
we´re not doing that, we´re sending markup with presentation hints
we don´t want to replicate those semantics in the css layer
cs: there´s a gray area in between
e.g., position of logo is meaningful, but difficult to express in markup
there is meaning in the presentation order of certain kinds of things
the separation of content and presentation doesn´t capture that
mk: @@
jn: the algorithms are well defined
it´s not important that @@
what´s important is that the tab order matches the visual order
so it makes sense
normally top left to bottom right
<Zakim> MichaelC, you wanted to say the issue is that some things shouldn´t be re-ordered in order to preserve underlying meaning of semantic order
mc: think the gray area is that people don´t understand the separation of content and presentation
therefore muck it up
jw: don´t want to end up with presentation determining semantics
heuristics to correct bad authoring practices scares me
provide ways for authors to do it right
jn: don´t see heuristics
the spec is well defined
jw: there´s a default assumption that ltr-ttb is rational
author should make that decision
jn: author doesn´t know how content will be presented in different devicces
so can´t accomodate all layouts
would have move the dom around
cs: has dev and performance
costs
... long history of AT heuristics
and authors just won´t do the right thing
some level of heuristics will be necessary
fantasai: there are authors who specifically want to address a11y and want a way to do it well
need a clear model
when there is a basic default style sheet you can see if your page is a mess
it´s a good quick check
but lots of css that alters how things work makes that harder
mk: @@
cs: would like to remove ¨must not¨
some behavior should be unspecified, left to UA
mk: not understanding how it´s simpler for author
fantasai: in general css shouldn´t control a11y
if you get into doing that, you´ve got some that does and some that doesn´t and it´s a big mess
to figure out what´s going on
people won´t choose a layout module based on its side effect on a11y
mk: duplication of effort, author has to do what ua does
js: should authors have to think like that?
ideally css would be a magic box that allows them not to have to
<Zakim> janina_, you wanted to ask whether we can guide people to do the right thing, but still leave room for user agents to repair when repair is needed
I agree that encouraging people to do the right thing is a good start
when there is need for repair, it should be explicitly
mk: don´t think this is repair
it´s recreating logic
fantasai: author doesn´t need to recreate ordering in css
do it elsewhere
mk: @@
jw: author-provided dom order and tab sequence should be the sequence regardless of the layout
<fantasai> jw: but I can understand others might feel differently
mk: so we disagree on that basic point, should sort it out
jw: presentation should be distinct from document structure
mk: what about screen magnifier where things jump around on the screen?
jw: no, not saying that´s desirable
fantasai: on a well defined page
there´s a clear outcome
flexbox and grid provide enough information to create meaningful navigation order
maybe we could some up with a way to animate transitions in magnification so relationships still visible
best we can do is provide all the info UAs need to innovate the UI
there´s a big user education piece
default should be that visual and source are in sync
unless the author requests otherwise
then have to worry about people who are hand authoring and ignorant
that´s the ¨turn off css and check your page¨ message
ac ja
jn: it´s over-engineering to allow some things to be moved to front of tab order
when we have main regions and stuff
fantasai: @@
jn: authors sometimes fit things into regions willy-nilly based on what´s available
then have to re-parent the dom
fantasai: the order property is a lot simpler than moving stuff around in DOM
maybe a DOM function to reorder in one call would help
<cyns> question: why is it bad for the default experience to be that the screen-reader experience matches teh visual experience? Or, put another way, why should screen-reader users have to know/care about the DOM when other users do not?
<jasonjgw> In the SVG accessibility task force it has been argued (persuasively in my judgment) that directional navigation is distinct from logical/structural navigation, even where the two coincide in certain instances.
fantasai: there is a sub-grid feature you guys should look at
<fantasai> The feature is called Subgrids
<fantasai> http://www.w3.org/TR/css-grid-1/#subgrids
<fantasai> It's been proposed to move this to L2, or at least several implementors thought it wasn't necessary for L1
<jasonjgw> Work has been done to support directional navigation. Perhaps the distinction between two distinct navigation types is pertinent to HTML as well as SVG.
<fantasai> However, I think this would have a bad impact on accessibility, as it would encourage authors to strip markup in order to use grid features , see http://fantasai.inkedblade.net/style/discuss/subgrid-markup/
<jasonjgw> Janina: one purpose of APA is to embed people directly in spec development activities.
<jasonjgw> Janina notes that Leonie is a participant in APA as well as Co-Chair of the Web Platform working group.
<jasonjgw> Janina thinks we should establish a liaison relationship with CSS and possibly with other groups.
<jasonjgw> Janina: we are also planning to track more formally our work on specs; Michael plans to set up a wiki for recording such activities.
<jasonjgw> The wiki will document reviews, comments and dispositions of comments.
<jasonjgw> Janina notes that PF teleconferences used to be 90-minute calls prior to the introduction of ARIA, since spec reviews were discussed in depth. Janina suggests we cosnider whether to make the calls longer under APA.
<jasonjgw> James makes a counter-proposal to this suggestion that more of the work be done up-front rather than in meetings.
<jasonjgw> John suggests that 90-minute teleconferences be a special exception where this is needed.
<jasonjgw> Cynthia notes schedule conflicts.
<jasonjgw> Janina: consensus appears to be that 60-minute teleconferences be used but that 90-minute meetings may occur with suitable advance notice.
<jasonjgw> There isJames suggests that preliminary determination of whether a spec requires detailed review should be carried out up-front (not during a meeting).
<jasonjgw> Cynthia notes that requesting extra work to be done outside the hour budgeted for the meeting can be problematic
<jasonjgw> Janina is keen to take up ways of operating more efficiently.
<jasonjgw> John suggests that community group reviews be carried out monthly, e.g., on the first week of each month.
<jasonjgw> Janina discerns a consensus that community group reviews be carried out monthly, taking turns to carry them out as a shared responsibility.
<jasonjgw> Janina notes that there will be a public APA list for our work. The list will not be world writable.
<jasonjgw> Spec discussion (of reviews) will be discussed on the xtech list. Janina proposes providing weekly reports to the IG regarding the status of reviews.
<jasonjgw> It would not be expected that the conversation be continued on wai-ig.
<jasonjgw> Janina: when APA reaches a decision, the working group responsible for the spec would be notified, the wiki updated and the xtech list notified, as would the IG.
<jasonjgw> Michael: it's reasonable to review community groups once a month; monthly activity reports to IG are also reasonable.
<jasonjgw> More urgent matters can be reported ad hoc.
<jasonjgw> Katie thinks monthly reports should be fine.
<jasonjgw> Consensus: there should be monthly reports to IG and additional reports of time-sensitive issues.
<jasonjgw> Janina will note in the reports to IG that follow-up discussion regarding reviews should be taken to the xtech list.
-> http://w3c.github.io/pfwg/wtag/wtag.html Initial draft of WTAG
<jasonjgw> Janina: APA has a range of non-normative deliverables. Web Technology Accessibility Guidance - how to support accessibility in specifications.
<jasonjgw> Michael: in addition to the normative W3C/WAI guidelines, there is a need for a document that indicates how to make accessible technologies/specs. There is precedent for this in W3C. Michael has been working on it for a year as time permitted.
<jasonjgw> Michael: it has reached the point at which the structure is apparent and we can start working on the details.
<jasonjgw> He is unsure of how to organize the effort to work on it.
<jasonjgw> In developing the document, he started with a clear basis in user needs. He notes that user needs are implicit in WCAG 2. There are user needs related to document and multimedia formats as well as the many types of devices now in use on the Web. Michael has sought to categorize user needs; the categories are determined by technology type.
<jasonjgw> Michael: example - content needs to be perceivable in a modality other than that envisaged/produced by the author.
<jasonjgw> Michael: continuing the example, one way of meeting the need is to provide alternative content; another solution is to encode the content in a manner that permits transformation to diferent modalities.
<jasonjgw> Michael: user needs related to contrast - color and auditory.
<jasonjgw> Michael is attempting to collect user needs and to organize them in a disciplined manner. This enumeration of user needs is meant to be as comprehensive as possible.
<jasonjgw> User needs can be met by the user, the content author or the user-agent. In some cases, cooperation between these parties is necessary, e.g., in the authoring and ultimate presentation of text alternatives.
<jasonjgw> Some needs can be met entirely by the user agent. In other cases, needs can be met by the author without using specific technology features.
<jasonjgw> Michael gives an example of text alternatives and how the authoring/user agent requirements are specified.
<jasonjgw> Example: high contrast is a need that can be satisfied by the user agent and need not require the author to use the technology in a specific way.
<jasonjgw> Michael proposes to turn the technology column in this draft into guidelines for technology development.
<jasonjgw> There are ways in which content formats can satisfy the need for alternative content. Michael illustrates the point.
<jasonjgw> Providing mechanisms for specifying textual alternatives would be an example.
-> http://w3c.github.io/pfwg/wtag/checklist WTAG Checklist
<jasonjgw> Michael notes that the resulting document is bound to be large and that smaller checklists are also desirable.
<jasonjgw> Katie: we need guidance that can be used by API authors when building APIs that affect user interfaces. A checklist could be used to meet this need.
<jasonjgw> Katie notes that the requirement that data formats should ultimately be amenable to presentation in an accessible user interface creates requirements for those data formats, e.g., preservation of information about the natural language used in textual data fields.
<jasonjgw> Katie sugests that the document Michael is preparing should be treated as a living document.
<jasonjgw> Michael: the checklist will specify a list of conditions: if the technology supports a given type of feature then it can meet accessibility needs in the recommended ways.
<jasonjgw> Michael notes that an API section could be included in the checklist.
<jasonjgw> Katie notes that working group participants engaged in accessibility and who are involved in spec development in various groups can use and contribute improvements to the checklist.
ac c
<jasonjgw> James supports Katie's comment that checklists are needed, especially by those who are not accessibility experts.
<jasonjgw> James suggests taht the intended users of the document should comment and be engaged in its refinement.
<jasonjgw> Cynthia: there have occasionally been requests for documented/authoritative sources of advice.
<jasonjgw> Michael agrees with James that the checklist should be short and that sections can be collapsed which are irrelevant to the technology one is working on.
<jasonjgw> Michael notes, responding to Cynthia's comment on the use of spec templates, that the material included in accessibility sections of specs can be problematic and often it is necessary for the accessibility features/material be distributed in appropriate places throughout the spec.
<jasonjgw> John: the authoritative source of advice is often subject-matter expertise. In some cases, the fact that suggestions are based on authority/expertise can arouse resistance.
<jasonjgw> John agrees that embedding subject-matter expertise is the best way to undertake spec development but has concerns about the kind of resistance mentioned above.
<jasonjgw> Michael notes that the review process ensures that a range of people with relevant expertise participate, including those who might raise objections.
<jasonjgw> Michael would like to create greater authority by undertaking scientific research into user needs and how best to meet them. This can be achieved in part through engagement with the research and development task force.
<jasonjgw> Judy has received comments to the effect that horizontal review checklists have been insufficiently helpful in spec development. Those making such comments seem to take the view that a more detailed checklist, accompanied by more detailed user needs backup, would be helpful. would address this problem.
<jasonjgw> The concept of a document which could be used for self-study purposes by spec developers has attracted interest and initial approval by those with whom Judy has had conversations.
<jasonjgw> Michael is unsure whether there should be a task force to work on WTAG; he notes that there are people outside the working group who are interested in the work.
<jasonjgw> Mark expresses approval of the WTAG proposal and it is consistent with his own efforts to engage researchers who are building XML formats or new technologies to design with accessibility in mind.
<jasonjgw> Judy: in conversations with other working groups about taking accessibility into account, people often find it difficult to think of accessibility as applying beyond the user interface. In organizing the material and the checklists, it should be made clar how to think of accessibility as involving technologies beyond the user interface.
<jasonjgw> Janina affirms Judy's comments, noting the accessibility implications of APIs, for instance in how timeouts are handled and how users are notified.
<cyns> +1 to modeling on the MAUR
<jasonjgw> Judy notes that this issue has been addressed in the media accessibility user requirements. The same organizational strategy devised in that document should be taken in the WTAG checklist.
<Zakim> cyns, you wanted to suggest we add some examples of APIs that impact accessibility, and also some examples/discussion of where a new technology can be used to solve accessiblity
<jasonjgw> John: focusing on system requirements and user interface requirements has significantly contributed to the effectiveness of the media accessibility work.
<jasonjgw> Janina notes the value (illustrated by the cognitive accessibility work discussed in the ARIA meeting earlier in the week) of separating the technical requirements that need to be satisfied from specific technological solutions.
<jasonjgw> Matt emphasizes the need for examples that make general and abstract requirements concrete for those developing specifications.
<janina_> http://www.w3.org/2015/10/apa-charter.html
<jasonjgw> Janina reminds participants to read the final APA charter and proposes to commence discussion of our specific deliverables. PF has been extended to accommodate the transition to APA. The APA decision policy is based on the HTML acessibility task force decision policy.
<jasonjgw> Janina notes that we need to adopt this policy, refining it if necessary. The proposed document is a draft for the group to review.
<jasonjgw> Janina anticipates that we won't reach consensus on the decision policy until the list of participants in the group has somewhat stabilized with sufficient participation to adopt the policy.
<jasonjgw> Janina notes that COGA continues to be a joint task force of APA and WCAG; she also notes the research and development task force.
<jasonjgw> COGA is making progress in documenting requirements and should be ready to summarize these in a document.
<jasonjgw> There being no further comment, Janina opens discussion of deliverables.
<jasonjgw> PF and the HTML accessibility task force have approved preparing the Media Accessibility User Requirements for publication as a note.
<jasonjgw> Janina notes editorial issues with the current draft that may require a moderate amount of work.
<jasonjgw> Given the editorial changes, questions arise whether the modifications are sufficient to constitute substantive changes requiring a further call for consensus. There have been no suggestions so far that the changes are matters of substance requiring further review.
<jasonjgw> Janina notes that there are 15 references to UAAG that have attracted comments from the UAAG working group, including references.
<jasonjgw> Janina has determined that the sections of UAAG referred to no longer exist.
<jasonjgw> John has coordinated on this issue and the remaining item to be considered (as Janina notes) is to decide how to address the poor wording in the caption section.
<jasonjgw> Janina thinks her fixes to the editorial issues have not changed the meaning of the text but cannot be sure.
<jasonjgw> She volunteers to send out e-mail on this to engage the wider gorup.
<JF> ACTION: JF to review Janina's editorial change proposals [recorded in http://www.w3.org/2015/10/29-apa-minutes.html#action01]
<jasonjgw> Janina notes the cognitive task force that needs to complete its gap analysis.. Web Payments have requested user requirements similar to those prepared in relation to media.
<jasonjgw> Janina raises the question of how to carry forward work on WTAG.
<jasonjgw> Michael suggests using a subgroup rather than a (more formal) task force to undertake the work.
<jasonjgw> He acknowledges taht the structure of a task force can be useful but it is not always needed.
<jasonjgw> Janina, responding to approval of Michael's statement by Cynthia, suggests that a task force be used where it is necessary to engage people who are not otherwise involved in the group. Successful examples: HTML Accessibility Task Force, ARIA (once a task force, now an independent working group).
<jasonjgw> Janina concludes the organization discussion. There is an open agenda after the break.
<joanie> https://bugzilla.mozilla.org/show_bug.cgi?id=812687
Every year in the ¨how did it go¨ survey I lambaste the plan to have AC meeting overlap WG meetings. This year I´ll go further and say it killed us.
<joanie> http://codepen.io/aardrian/full/MavVeb/
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) Succeeded: s/follow the screen order/follow the screen order if I told you to read me the page/ Succeeded: s/@@/HTML has dir attribute so we don't need to do that in CSS/ Succeeded: s/presentational/spatial/ Succeeded: s/markup determining content/presentation determining semantics/ Succeeded: s/won't/shouldn't/ Succeeded: s/bAPA/APA/ Succeeded: s/a more detailed presentation/a more detailed checklist, accompanied by more detailed user needs backup, would be helpful./ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Found ScribeNick: jamesn Found Scribe: MichaelC Inferring ScribeNick: MichaelC ScribeNicks: jamesn, MichaelC Present: Cynthia_Shelly James_Nurthen Janina_Sajka Jason_White Jesse_Beach Joanmarie_Diggs John_Foliot Léonie_Watson Mark_Sadecki Markku_Hakkinen Matt_King Michael_Cooper Takeshi_Kurosawa jessebeach Taketoshi_Yamane Takeshi_kurosawa Taketoshi Yamane Wang_We Can_Wang JF Kenny_Zhang fantasai Agenda: https://www.w3.org/WAI/PF/wiki/Meetings/TPAC2015/APA Got date from IRC log name: 29 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/29-apa-minutes.html People with action items: jf WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]