APA FtF Day 1

29 Oct 2015


See also: IRC log


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


<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


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

Post break demo and discussion

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/

APA organization

<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/

<joanie> http://codepen.io/aardrian/full/MavVeb/

<joanie> http://codepen.io/aardrian/full/MavVeb/

Summary of Action Items

[NEW] ACTION: JF to review Janina's editorial change proposals [recorded in http://www.w3.org/2015/10/29-apa-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/29 08:42:09 $

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)

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


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]