ARIA FtF Day 2 -- 27 Oct 2015

<jamesn> scribeNick:jamesn

CS: SO the topic is script based accessibility

Script-based A11y

3 inputs WAPA

Indie UI Events

Web Accessibility API from Mozilla

so what I was thinking is that we would talk about use cases and what we are trying to achieve

the use cases of the 3 proposals overlap then need to look at the 3 different proposals and how they might meet the use cases or not

the ideal is to have 1 propoal in the end

side piece is that platform APIs have a bunch of pieces which oeverlap but some that don't

Web apis may need some of these to platform APIs may need to fill some holes

Does anyone have use cases?

So - 1 of the big use cases is virtualization. 2 really good examples. 500 page word doc. don't have it all in the dom. you want you AT to know you are on paragraph 342 for example

long lists are another example. search results, facebook feeds etc. are other uses. you don't have the whole list in the dom

another use case we have thought about is increasing performance

the winjs control set - a JS control set - has a list control. They were managing the posinset and setzise in aria. found that pushing all those strings around was costly

2 things looked at. 1 was exposing the properties and another was an event which gets fired when there is a call from the api so you can react when someone is listening

so not pushing the strings around unless consumed

we are less concerned with automated testing

MK: if you are doing automated testing of a webpage. simplest example is does it have a name. essentially in a test tool you have to implement the name calculation yourself

RS: 1 of the problems with native plaform testing. on the mobile devices for androis and apple the apis are undocuemtned

would be helpful to have 1 consistent layer rather than having to test on each platform. would love to not have the mapping guides.

had the discussion with JC - asked for mappings. repsonse was that we are the only at so why do we need to supply this

one of the things we need to do is have device independent interaction. lots of the indieUI stuf f we need to look at

largest cost to web apps is keyboard support.

any API that we do do - lets say if there is a property change - i dont want the web app person to send the event to the at

we should be able to do that and make things easier for authors

CS: there are use cases for both of those. there are times the compoentn needs to fire the events and the other times the browser should do it for you

i hear authors wanting more specific control

RS: i hear they want to force things

MK: we don't want that

RS: different types of authors
... power users and others
... the 2 have to be able to operate together

CS: I think there are models for that in other places

RS: we enforce structure in aria. a problem in early api dev is we didnt do that

try to fit properties into buckets of apis

they include the state information in labels

etc

we are giving a bigger chainsaw

going to require thought

CS: want to design a socket set not a vice grip

AS: 2 things
... 1 part is provide access for testing and screen readers and other AT to enable a screen reader is JS for example

the 2nd is alternative to aria where don't have to deal with DOM. Can create the accessible object in JS and feed to the AT

<Zakim> tzviya, you wanted to provide use-case of data-based simulation

TS: some of the use cases in the world of publishing could be DB simulations

where have a huge data set and dont want it loaded into the dom. There is a simulation - a CSV for example where a user can maniuplate a graphic in some way

an example in journal publishing

we are strugling how to make it availble

CS: someone i know had an econ 200 class where there was a flash object where could move things around

RS: with control patterns this will get addressed. don't currently get input events from AT
... web programming model is different focussed in events coming in. MSFT model is nice but there are 2 sifferent groups. web and native and need to look how work

CS: an event could bubble but not every thing in the chain handles it

probably ways around it

lots of interesting things. how far should onclick bubble etc

tricky area

JB: wanted to understand who the sudience would be. there are conflated asks
... 1 would be access to the a11y tree - then the ability to interact with that information
... who we talk to next would inform what you would ask for

CS: office needs to do stuff like in the native plaform applications
... other complex web applications have the same issue

JB: from the perspective of the FB newsfeed. I don't think we would want write access to another model of the inforpmauton. Has the risk of getting out of sync
... potential for collisions. the 1st xhort step to make the a11y infromtion. Make the tree read-only first.

CS: In browsers with a tree that makes sense - not all do

RS: 1 thing in the 508 refresh is that can change state from an application
... we devs dont expect the dom to change from AT

spent about 2 weeks on revised wording on the refresh

maybe we do do that

CS: office barely touches the DOM. Want to do everything in the JS layer

JB: if you look at angular , react etc. the model is treating the DOM as the state of the application

CS: enabling a different style of dev

there could be ways to mix that would be bad practice

and others not

CS: if a Checkbox was just a JS object and an image then could react to it

JB: would love to see prototypes

CS: With edgecan go into about flags with accessibility experimaental
... the WAPA demos should work there

<Zakim> jamesn, you wanted to ask if anyone has discussed the privacy implications

<MarkS> JN: privacy could be an issue and we need to think about this carefully.

RS: in Vista UI Automation was for testing then added the accessibility on top of that
... could be automated test procedures - could be stuff on mobile

TS: epub in germany is not kindle and they have a bunch of accessibility preferences

CS: are there other use cases which are difficult to solve in markup

RS: content editable. need to move the caret - an API which would convey the inforomation to notify the position within an object, when focus moves etc
... normally 1 person working on content ediatble for the browser

CS: webapps has a whole TF on editing

RS: if there is no api then you are hosed

<tzviya> ebook reader is Tolino Shine: http://mytolino.de/ (in German)

CS: 1 thing i like about wapa is that it builds. we built ontop of the stuff they were doing in the editing spec

RS: 1 thing that ia2 and atk do well is the location of charcters. early UIA disn't do that
... table support is horrific in some platforms
... some of the things we do in rich web content like embedding stuff in tables. need to look at the apis to find out where there are gaps

CS: editing is a big use case

JW: raises some questions

all the UAs that work on multiple OSes have an internal api which is bridged to OS API

that is the layer you are suggesting may be connected to

related to the APis of the OSes which could be taken advantage of

also interested in the realtionship between any api and what happends in the DOM

some Apps make use of the aria attributes to control the UI. A legit use case - doesn't breach the constraint on aria of requiring the UA to do stuff but does allow the author to take advantage

in HTML have a distinction between IDL attributes and content attributes - what is the makrup and the JS. the IDL attributes represent the content attributes

could create IDL attributes for all the state and property attributes. can think about how we want to do that

connection between any events related proposal and the indieui event work and the WebPlatform WG Editing work

what we want is a uniform treatment of intention events which would apply however those events originaTE

IF GOING TO see more semantically expressive event types on the web then need a more uniform treatement

see how we can harmonize work in this area

RS: said not using the dom. how are you doing styling on the object model

CS: not completely sure. in the doc area

they keep the visual rendering and the semantic rendering seperate. have some black magic

<joanie_> history

kind of like a shadow dom kind of thing

the a11y information is in JS objects

want something more similar to windows

RS: what they are doing is creating a different object model. almost non-web

CS: i believe google docs works a similar way

RS: would make it very hard to do what JW suggested. if trigger off object model then not going to be reflected

CS: you are getting JS events. If design is such that exposing stuff to the user. can react to the toggle event and check the checkbox. there is a JS object and DOM object. In reaction to the JS event the script changed the JS object representation and the DOm representation
... dont have to haev 2 trees but some do and no solution currentyly

RS: may not want to map the dom at all

going to be very challenging

have 2 differnt trees. 1 has focus etc.

CS: like canvas

JB: when i did a visual representation through canvas without dom.
... there are similar proposals out there. Would like to hear more from Alex. the moz proposal as i understand it would create an association between a11y node and dom node. sounds like MSFT doesn't have that at the moment

how to resolve this

JW: the possibility of what is in the dom being inconsistent with the a11y api. Have concerns about anything that may compicate that
... the information about the a11y related state is maintained. If there are performance concerns.

anything with 2 trees which aren't connected is of concern

<Zakim> tzviya, you wanted to talk about multiple OMs

TS: observation

multiple object models. concerns from multiple groups

css object model, css selectors to create annoations, and shadow DOM

if we are concerned about 2 what happends when there are 4

i heard your concern jason - but this is a very advanced scenario. devs with multiple trees would be responsbile for keeping them in sync

big complex commerical apps with developers on it. sometimes you need sharp knives to do a job

would not expect a web site dev to use them directly

agree that trees in sync is hard. but already the case

DOM, Shadow doms, fallback content, etc. etc. etc.

all exists now. what i am trying to achieve is some sort of not stupid way to communictae between those layers

RS: dont want test tools going to the api layer
... need a layer in the browser that handles all of this

otherwise need to think how going to test thos

want to have a way of testing across devices

CS: working with a11y the mac office team did a bunch of work.

seems unliekly to me that we are going to put a layer in the browser

don't see it as likely

We also really want a web app and windows app to act the same

office for win and office for android etc. the user shouldn't have to care. visually that is largely true now

not there yet at the a11y layer

RS: if push to the native plaform then going to be very scostly
... test it once - if platform layer has a mapping bug then it is a bug

can stop their work there

need to have something that runs across platforms. need things to be consistent

CS: we wire more directly from the DOM to UIA
... does this app work the same is our test practice

a different angle on it

RS: my product teams. can test once in the browser and then with ATs on the platforms. Can't do special API tests on the plaforms
... we like not having to do that

CS: both scenarios are real

RS: what we do now is use webdriver - run a11y test tools right off that infrastructure. go into the dom and test

that has a limit in that we have those other object models where you can get that

i was thinking of that as being the webdriver testing work

CS: have a test that does a bunnch of ui actions then checks that the right results and the right a11y events got fired etc. etc. etc.

so i know when AT consumes the api we know everything got through

RS: If I am creating the web application i don't want to test that the apis go to the browser

lets think about aria 1

browsers didn't have full api mapping support. do i not ship becuase a browser doesn't do the API? People hack around the bug

the average app developer can't call the edge team

CS: 2 assumptions is that all the browsers have a lot of work to do on mapping. if that is done it should be the same thing testing the dom vs. the API

RS: yet to see that happening

MK: more likely to happen if do cross browser implementation

CS: used to test at API layer - found that didn't correlate to works with AT

AT on windows are spaghetti

RS: the way it is

CS: do you see it being used primarily for testing or also for web apps?

AS: writing a screen reader for web devices and we needed this

CS: is this implemented

AS: yes based on XPCOM stuff

no demos

CS: Is it on by default

AS: yes but have to have permission for it
... Our old API is exposed. connected to the DOM but different tree

CS: can you send directions on how to do that

from a plugin

<timeless> scribe: timeless

AS: we sent to the Group our draft
... it includes the ZZQ kind of interfaces
... IAccessible2 interfaces
... the second is AccessibleStream Interface
... virtual cursor, allows you to traverse web content
... traverse text stuff and accessible object

<asurkov> https://wicg.github.io/a11yapi/

AS: not yet finished, you can get an idea about it
... other parts I didn't push yet
... you should be able to write/describe what role
... what states/actions/etc.
... if you introduce new role extensions, like DPUB extensions
... you should be able to describe--write in JavaScript what the new taxonomy is
... what relationship between this stuff and existing taxonomies
... browser should be able to map new stuff into existing Accessibility APIs automatically
... that's the third part
... the fourth part is to write accessible interfaces right in JS
... useful, if you don't want to use ARIA
... you don't want to put accessibility stuff right in your web content
... you don't know if you have any consumers
... so you describe accessible objects in JS, create when asked
... or if you want to create stuff that doesn't have DOM, like <canvas>
... or other wild-web-content
... these 4 things I want to happen

CS: other parts of this document we should look at?

AS: I think you referred to this

<asurkov> https://wiki.mozilla.org/Accessibility/WebAccessibilityAPI

AS: it's an early document
... good enough to get an idea about
... the taxonomies and creation of AccessibleObjects in JS

CS: these objects map directly to your intermediate layer?

AS: yes

CS: you're creating the same kinds of objects that are created/mapped from the dom

AS: yes, that's the idea

CS: and they're automatically mapped to the platform APIs

RS: that's nice

CS: yes

RS: it would help testing dramatically
... the model is nice

CS: yes, that's nice
... we don't have that in our model
... but we have stuff like this
... stuff we have in WAPA
... let me look
... or can you, [AS,] talk about events?

AS: events aren't finished
... events should be able to say "i want to do this events on this tree"

CS: do they raise JS events if you get a call from the Accessibility API?
... if you have the A11y Tool sending an event to a [synthetic] object, does it trigger a DOM event/similar?

AS: not sure it should be DOM events

CS: ARIA does a good job of sending out, but doesn't do a good job of handling in

RS: It doesn't do a good job at all

CS: I was being nice

RS: I like the intermediate layer
... very thin

CS: I can't commit to that
... maybe it's just a mapping

RS: test that across platforms, if it doesn't work, then browser needs to fix it
... I don't think we need to have authors test across browsers

CS: I don't think it has to happen, the 1pm meeting has to handle that

ack

JB: the A11y object has a link back to the DOM node
... if you're writing to the AT Tree, and the DOM node updates
... would the object piece be overwritten by the update?

AS: I don't know that we have an answer
... if you create a JS A11y object, then you just override everything
... if you do, then you're responsible for the semantics you create
... not very sure about this, maybe we should try to find a balance from the DOM semantics and your object

JB: w/ the AT rep, and the ability to create Nodes
... you could create an AX tree with no representation
... divorced from the DOM they kind of live in this intertwined world
... I always saw this as a read-only tree
... there's a lot of complication when you can try to write to it

AS: it's true

[ common laughter/agreement ]

CS: but we're trying to do this
... if you're creating a knife...

MK: need a knife case

RS: good to have a knife, but want something for people who don't need an Axe
... if we want to create an app, and have a handler

CS: I think the more common scenario is mostly markup w/ this sprinkled
... but some scenarios w/ all JS

MK: is it possible to set pretty simple limitations
... if something is in the DOM, they wouldn't be able to manipulate it through the tree
... if it is in the tree but not in the DOM
... something that makes conflicts very difficult, or almost impossible
... so people don't cut their foot off w/ a knife

CS: yes, I don't know what it would be
... but we'd need to make sure it doesn't block the intended UC
... we need to look very carefully

MK: very serious consideration
... people who are writing JS are not necessarily aware they're holding a knife

[ laughter ]

CS: true w/ a lot of the stuff we have now

MK: the AT is essentially invisible
... something that goes along w/ this that changes that
... you can't ignore the AT in some way
... no idea what that would be

JN: the AT will need to be less invisible

CS: yeah
... this functionality would allow you to build more plugins

<tzviya> +! to less invisible AT

CS: see what's going on
... plugins that integrate w/ F12/Firebug

MK: people using JS functionality to see what's going on
... highly visible

CS: ... in your face even

MK: the browser can be aware

CS: the UC I'm trying to solve in Word, the way Word thinks about documents, and the way HTML thinks about documents
... are radically different
... the visible DOM tree looks like HTML, but
... the team wants it to sound like Word, not HTML
... yes, it's a very advanced scenario, and most developers don't have to do that
... AS thanks for joining us

[ Break until 11am ]

<MarkS> scribenick: MarkS

IndieUI

RS: mark parts of your document that have actions
... event gets triggered, then that area can have an event handler associated with it
... as long as the point of regard is in that area, the event bubbles up
... must have a handler to handle these actions
... can be generated by a trigger in your web page or by the browser
... maybe ESC will close a browser
... browser will look at the context the command was issued in
... here is an example. dismiss. a UI action. point of regard has to be inside this UI action dialog box, in this case
... there is an event listener.
... author writes a handler to process event
... here are different actions
... collapse, delete, dismiss, expand, etc.
... there are more, just not in last published draft
... want to talk about triggers. you can put one on a button. anything that has a click, the action will trigger the device ind. event
... trigger event, cause a dismiss, PoR inside here, have a handler that responds. these can come from the browser or the application.
... the browser responds to device specific actions.
... could be a voice recognition command that triggers the closing of the dialog box
... you can programmatically determine where these are supposed to be triggered
... good for testing. want to know where response is happeneing
... events get fired and they bubble up, same as it currently is
... if you have a control pattern, you would just have a method that responds to the dismiss command.
... is there a control pattern for dismissing a dialog box?

CS: there is a window control pattern that has a lot of that]

RS: what we don't have in ARIA today is the ability to do these higher level actions
... we can do this through the object later.
... add a method on that element
... we have two different models at play here.

JW: there are some open issues. including the fact that we hadn't reached consensus on how to deal with value changes.
... like a slider control, by a pointer device. how would that be handled?
... use indieUI events to change values of UI controls
... other difficulty is that we determined that this work would be best carried out elsewhere
... webapps seemed like a logical place. intention events.
... interest in editing APIs
... seemed interested in merging work
... no decision about where we go from here.
... benefits to indieUI events is that the events can be generated by all sorts of devices, don't need to be assistive technology
... easier for authors
... no handlers for all the possible events.
... the UA would determine how those are triggered
... not effort to let authors customzied the particular events, just the abstract events
... may be future work
... this is not accessibility specific, which is its major advantage.

RS: we talked about value changes and things like that.
... there needs to be a standard way to get at the current value and how it gets changed
... could be generated by an API
... this is where a common layer API would be a benefit
... scrolling the scrollbar, you need to know where you are and what the increments would be

JW: james craig had specific implementation concerns that weren't very clear
... no way to change the value of the UI control. read not write
... control could be several components,
... we didn't fully understand the challenge

<richardschwerdtfeger> ack

JS: we didn't ask for recharter. if this is going to succeed we need developer participation, which we didn't have
... putting all of this together is the right thing to do. if we look too much to web platform to push it, it might not make it over the finish line, at least in a way that supports our needs.
... i think we will be expected to drive that work

CS: i think we all agree that we want to do that

RS: web platform is only chartered for one year

CS: its currently in an incubation group
... recruiting people to work on it with us

RS: the ARIA WG is chartered for 3 years. if it doesn't work out in the incubator, we can pick it up here.

CS: the incubator purpose is to grow it and then find a home for it.
... where it fits best
... I'm interested in hearing what people think about the common benefits and gaps of the three proposals

RS: i don't remember seeing details about the commands

CS: yeah, he said he didn't get to that yet.

RS: here is how it maps to AAPI, but not back again
... that is why i like control patterns. can be used for testing.
... do we do eventing model, methods at object level...
... UIA provider layer
... this is like ATK and AT-SPI,
... DBUS

CS: any ?'s about IndieUI?

RS: i do know that apple has implemented a little of this.

JB: looking at the set of actions. it seems CRUDdy
... it seems to have some medium relations. i wonder if there can ever be enough tokens to represent all you can do in an application.

RS: it didn't end up in the browser,

CS: we weren't 100% on the shape of the API

JB: three part event structure. bubble from body, initial target, then the actual target.

CS: one of the reasons it stopped where it did

JB: this needs to a happen at the device layer. they are abstracted away componenents

RS: each platform has their own layer. need a place to map it.
... how we do it, not sure. this may not be best.
... we have to figure out how we handle bubbling, or if we do it at all

can it be done with handlers

MK: is the question do we have to do it?

RS: you have a touch interface on the mac. different than how it is done on windows and there is IP barriers so they couldn't be shared.
... on the platform, what gesture triggers what is different across platforms.
... then there are the differences in keyboards on various platforms
... faster to execute this in the browser, not in the app

MK: if the people doing all that work today, think its all that difficult and really need this.
... maybe they are fine doing that work.

JN: you also have frameworks that aren't doing this and don't even allow some of the interactions we need.
... they don't work on various touch OSes
... you don't get that event on sliders for instance.

MK: sounds like an implementation gap

JN: every framework shouldn't have to do this

should be done in the browser

RS: keyboard alone, keyup, keydown, ESC, mac has a whole collection of commands that don't map to keyboard at all
... authoring practices document refers to specific keystrokes that don't exist on mac for instance
... if a JS framework has to handle this, they shouldn't have to.

CS: do we know if framework developers are bothered by this?

MK: there is a tendency to move away from frameworks

JN: our developers would like to not have to do this stuff
... they want something like IndiUeUI

JB: seems like if there are semantic gaps in the token list, say 75% of behaviors represented, i imagine developers would rather just be consistent with how they approach these challenges
... not sure we can handle all the possible tokens
... in HTTP you have put, get, post, etc. then the stuff that HTTP doesn't cover

JN: there is a finite number of things you could do on a touch device.
... could probaby cover most of the scenarios

RS: multi-touch devices. its currently handled at the OS level

JN: requires passthroughs sometimes

MK: do we know how this would have been affected by force touch?

RS: apple is not going to release how they process 3d touch
... we're just trying to open a dialog

CS: time to demo WAPA

[DEMO]

CS: using Inspect. aria properties added when I connected via inspect
... onariarequest event was triggered when Inspect connected
... call to build the tree, triggered those aria attributes
... in the DOM
... you don't have to use the DOM, but you can
... here is a list 1,2,3, and 100
... inspect populates tree
... triggers onariarequest
... sticks aria-posinset and aria-setsize

JN: Dragon will not benefit from this because of the way they interact

CS: here is a checkbox
... i will call toggle method from inspect
... will trigger handler
... toggle event comes in. has attributes on in. i handle that event, and I grabbed check state of checkbox and toggled it
... an expand event would not trigger this.
... inspect can trigger options. will call toggle, it did a couple things
... visually, I swapped graphics
... then I added aria-checked state
... i used the DOM, but you don't have to
... you can react to calls fro mAAPI, and you can react to more than just click
... UIA has more than outbound methods
... multiple inbound actions is something that UIA has that other APIs don't
... the idea is that AT can interact with browser app the same way it interacts with native app
... currently the experience between native and web is very different
... even if visually they are the same
... this solves that

RS: something I like about control patterns. microsoft has been doing testing with UIA since vista. when it first came out, it was kind of ugly, but since then, it has improved a lot.
... i remember just 7-8 control patterns in the beginning.

CS: patterns can be composited
... tri-state buttons would have invoke and toggle, can combine, there is expand, you an describe the behavior of an object, etc.
... curious what people thing about these three approaches

RS: in terms of device independent interaction. this is a lot farther along
... with patterns, you are able to get access to states and properties.
... there is a lot that needs to be investigated here.
... there are gaps in UIA. the way they handle text

CS: its better but still needs work

RS: IA2 text works great with AT
... is there a way we can pull all of this together
... Alex is maintaining IA2 now. its used on Chrome, firefox, eclipse
... there are things that are on mac that don't exist in IA@

CS: amazon fire has a new AAPI too

MS: brings up security

CS: there is a slight risk, but details about AT are not revealed, just that AAPI call was made
... and touch uses this API

[LUNCH]

<joanie> scribe: joanie

<MichaelC> scribe: jessebeach

Action 1725 Article Feed

<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/actions/1725

MK: Problem space - continuous scrolling is one part of the probelm space
... Original issue 633, the limitation of elements like listbox; when you put any content inside of an option, because that option is the child of a widget, the only thing available to the AT, the content items lose their semantics
... An inherent limitation of all of our widget roles, whether it's treeitem, option (containers); their inherently static
... That's limiting if you want to flatten your navigation structure, such as putting nav items into a list
... We have a need to be able to create components that AT user (screen reader users) can read but still have some level of interaction with
... For ARIA 1.1, bec/ of where we are, bec/ we have immediate probelms that we want to solve, we might need to compromise and adjust the semantics of existing roles
... For the case of creating a list of links, checkboxes (etc), I am proposing we use a grid for that purpose. A grid cell is a container and the elements in that cell retain their semantics
... In forms mode of a screen reader and you put focus on a grid cell, then the content of the cell does get reduced to a named string
... One of the proposals, if you have a single interactive element, it's perfectly fine to reduce the content to a contained element
... Bec/ for them to do the reverse, to receive the information that a grid cell received focus and it contains a button, that's hard to do
... But to focus on a button in a grid cell, it's easy for SR to say that a button is in a grid cell
... If you're using a grid to creat ea collection of links and you wnat the screen reader to be able to say and you're navigating with the arrow keys in the grid, the web application has control, you want the SR to be able to announce the complex content in the cell when the focus is on the grid cell; instead, put the focus on the content and then the AT will announce that the content exists in a grid cell
... In the case of an infinite list, in a grid, the web app will have control and it will now how to place and move focus
... it's an easy way to solve simple, interactive lists that scroll continuously
... The harder kind of interactive list to make is like the Facebook feed, where every story in the feed is an article
... To solve the problem where we want the content of the page to be able to read by the screen reader in browser mode, bec/ what they're looking at is content. They're not interacting with static elements that can be put in a widget, you're looking at links, text, pictures...
... You want the user to be able to move from article to article, and interact with the content, and you want the scrolling to work well
... Currently, the hack in place, is to establish a handshake between the app and the screen reader and pass through keystrokes for navigation.
... For example, the j/k keys move down and up the news feed
... Have site-specific keys for moving between items in a feeed, that steal the ability for SR users to use built-in navigation keys, is a problem
... The suggestion is to inflect containers with a property that indicates that the container is a feed; that a container has items that will be adding and removed and it is consumed
... The author makes each element in the feed focusable, and scrolling + positioning is left up to the author
... In the context of the feed, when an item gets focus, the author is responsible for moving it into focus
... Articles are not landmarks, they're children of document which is a structure

<mck> http://rawgit.com/w3c/aria/mck_issue633/aria/aria.html#articlefeed

MK: The article feed roll is a special use of the ARIA feed property (not finished yet)
... I eliminated aria feed pre- and postpend
... Article feed is a child of list, and instead of having listitems as children, it has articles as children
... aria-feed is a boolean property
... Articlefeed is a child of List
... correction, Articlefeed is a sub-class of List
... aria-feed is a boolean property that indicates that new items will be added to the feed
... What about a grid inflected with aria-feed?

RS: You have an ArticleFeed, which by itself its a feed. Why do we need aria-feed as a property?

MK: Articlefeed is necessary because its children is an Article, which would need to support posinset; it would also support aria-describedby
... aria-describedby allows an author to define a skimmable summary of the articles

RS: What happens if you put aria-feed="false"?

MK: I guess it means you're no longer adding content to it
... What happens if you put aria-live="off" on an alertdialog?

RS: The alertdialog would beep; it's an alert

MK: alertdialog says if you aria-describedby, it speaks a summary
... you can have role="alert" and aria-live="off", it doesn't make sense either

<Zakim> joanie, you wanted to ask about why aria-setsize of -1 could not serve for the purpose of there being more stuff in a grid

MK: aria-feed is only necessary on structures, not widgets

JD: posinset and setsize are not supported on article, but do we need an articlefeed role?

MK: Maybe we can use aria-setsize and enhance its meaning. We do need it to apply to the container and currently we do not put aria-setsize on containers

JD: We have properties that maybe need to be modified so they apply to these use cases

MK: I'm totally game for aria-setsize to be applied to containers

RS: Does aria-feed have to take a boolean value? Can it be indicative of size?

MK: I'm game for using aria-setsize = -1

JD: I'm saying we don't need feed properties and roles; scratch all of that is my suggestion

MK: When it comes to aria-setsize, the container of list or table, when you put it on the container, it's going to have a very specific meaning, it will indicate that more rows or items could be added; if we're going to define it that way, then it needs to be on the container, not on the items

JD: Orca doesn't have this problem bec/ it doesn't have a virtual buffer; the only time this problem is relevant is when the cursor is on the last thing

MK: It's also relevant to the user who is moving through a list and needs to know there won't be an end

JD: What's the reason for putting it on the container?

RS: If you had setsize -1 on the container, it's not because I don't know or because it's a continuous feed

CS: It's necessary to know that the set size is unknown

JD: Given that it is on the item, could we apply them to articles, and solve the problem without a new role and property

MK: In the case of article, hows does anybody and esp. the AT, know what is the container and what is the next element.

JD: Why do I need to know what the container of the articles is?

MK: to escape it

JD: Why does the container have to be anything

JN: Why aren't they just listiems in a list?

RS: Why can't we say something about lists and grids, to treat the individual units as articles

MK: clarify

RS: In a list, the listitems are articles.

MK: The container would be a list, the children are articles
... As soon as the container is a widget, you're putting the SR into forms or focus mode and then the only content you get are names

RS: By calling it a feed, we don't know whether to go by row or cell in a grid

MK: aria-feed doesn't make sense on grid, just on structures

RS: Ok, so you want aria-feed on table and list. In the case of a table, say it's a feed, do you move by cell or by row

MK: in the case of a table, if you're moving down or across, it's up to the app to take care of focus

RS: OK, so in a feed, if you're going by what's focusable, how do you know what to go to?

MK: The listitems, the cells, they would be focusable with tabindex -1
... So that SR and screen magnifiers, when using quick keys, they'd get focus and the web author can take care of the scrolling

RS: Is it possible that you're in the last cell of the last row and the browser hasn't loaded in any more content and there's no more content to move onto

MK: That's a web author's problem
... Well, maybe it is a problem. It's certainly something to...

RS: I'm worried about relying on the AT to set focus

MK: This is solvable as part of the handshake. If you're going to do this, it needs to be clear to web authors. If they expect scrolling to continue and you're on the last item, more items need to be loaded

RS: I would prefer to let the author set focus and let the AT follow it

MK: But then the author needs to listen to keys, not just focus
... if you're going to make it AT independent, they need to set focus. All ATs can set focus
... Setting focus works on every platform. Not having something to set focus on would be an application defect
... If the last item in the feed has focus and the author doesn't load more items, then it will be an application defect

RS: you're asking the author to do too much

MK: Right now we have a hacky solution to do this. It's not standard and it doesn't scale. It's not a problem unique to Facebook, Twitter and LinkedIn
... There is no standardized way to solve the problem of scrolling through a feed in a standardized way; they result in poor performance

RS: In ARIA 2.0, we'd have a pattern for feed
... We're hacking with tabindex here

MK: That's a clearly supported feature

RS: What if you don't have an AT

MK: If you don't have an AT, we can provide geeky keyboard support like j/k and more friendly like page down; none of that requires ARIA. To have a handshake with AT, we need a handshake
... Right now, AT are trying to make this work with IA2 scrollto; it doesn't work

RS: I don't think this handshake is reliable; there's a problem to address, this might not be the way to do it

JB: Is there a way to indicate business, to deal with async loading?

MK: aria-busy is in the proposal

RS: There's no limit on what can get tabindex

MK: We're not limited to what gets tabindex; we're not looking for elements with tabindex; we're looking for children of the list

RS: It would be helpful to be clearer
... aria-setsize -1 on a list feels like magic

JD: Why does it need to go on the container?

MK: I'm still pushing for an articlefeed role

JD: What about flow-to?

MK: Let's not confuse that with more info

RS: Do we have to have this on a table? Can we limit it to list?

MK: I'm ok with just putting it on list, but then I want to fix the ontology. Menu and list inherit from list. I don't want aria-feed to be inherited by list box

RS: What about just Articlefeed

MK: OK, then we could just skip the aria-feed property

RS: We're trying to get this into ARIA 1.1, this scope is growing and it feels like we're trying to get the toothpaste back into the tube.

MK: The more general solution seems to be problematic, let's just focus on Articlefeed role; it solves a specific problem
... the other issue, that creates an interactive list, we'll do that with grid and it just involves changes to the description of grid

RS: Ok with that?

JD: I'll wait for the proposal

RS: you don't need posinset for set size

MK: You don't need it, but it would be nice

RS: but it wouldn't be required

MK: yes
... articlefeed is a descendant of list

RS: So you have aria setsize and posinset, you can just set those on article
... User agent should not be managing setsize and posinset for a feed

MK: If you don't specify set size, then the AT just assumes the size is the number of items in DOM

RS: if it's a feed, then why is setsize need?

RESOLUTION: Add aria-posinset and aria-setsize to article

MK: The purpose of aria-describedby on an article in an articlefeed is to support skimming

RS: Do we say "screenreaders may"? Do we have that in other places?

JD: I think we use Joseph's "it is suggested that a screen reader might".

RS: If you [Matt] could say "assistive technologies" that would be better. And it's a glossary item, so you can refer to it.

RESOLUTION: Accept Matt's ArticleFeed (pending editorial review)

RS: We'll do the main, the document and the grid in the next meeting.

MK: I finish the grid and the document role

RS: We'll do that at the next meeting

<mck> scribe: matt_king

COGA taskforce interlock

<Lisa_Seeman> https://rawgit.com/w3c/coga/master/issue-papers/links-buttons.html

<inserted> ScribeNick: mck

LS: Quick intro to COGA proposal for additional semantics

There are 2 groups looking at the proposal for implementation

EU project and an Open Source project

First issue: add support for people w/cog disabilities without undue burdon

If at UA or AT level it could add soe extra support.

2nd use case is familiarity

For PwD who do not want to struggle w/discoverability, familiarity is helpful

3rd use case is simplification

Automated simplification often gets it wrong.

We need info about what things are on a page

Originally called it importance, instead of simplification, but that caused issues because who is to say what is important.

This is early draft.

Looking for feedback.

We want to enable more people to use same content by adding more information.

RS: most of what we hhave done w/aria is interoperability.

What we are doing here is new semantics to drive the UI

<Steve> MichaelC: thanks

Example, if you change the look of help button or move it, then people wonder what happened to it.

<Steve> +1 for demos

COGA is the first time we are really looking at first in terms of using aria for stylig.

<ayelet_seeman> https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html

<Steve> yes

AS: describing demo page

<Steve> Lisa_Seeman: I'm getting a crazy echo

Showed a page that is cognitively complex.

Use a personalize button and the "main" changes to "home"

Symbols get loaded.

Some content is removed.

It is possible to progressively simplify the page.

In the EU project, will let you load different personalizations from a JSON object

<Steve> that is great!

<Steve> echo just died - thanks!

RS: what does aria-simplification take for values

LS: Simplest is used on elements are essential, e.g., send in e-mail

Critical on an element that is used very frequently

Add some point we may want to add context information to help determine for which audience something is essential or critical

eg, mens clothing not important to women

Medium could be labels on an e-mail

Nothing is being deleted from the UI, just tucked away in some kind of more options function.

Another feature is to add context with aria-actions .. used to be aria-function

and also with aria-destination.

RS: There has been huge discussion around aria-destination to see if we could use rel attribute instead

LS: All aria attribs have been for a few disability groups. Cognitive is probably larger than all the other groups.
... if people are concerned about proliferation, then let's at least start from an even point and have as much aria for cognitive as we do for other groups
... There could be a lot of junk in rel that is not useful or relevant to cognitive.
... so how we do we avoid confusion because of that junk.
... Is there an issue with who is in control f the attribute?

Here we are separating destination and action into 2 separate things.

aria-destination says the type of destination and aria-action the type of interaction.

<JF> I'd like to point out that the the taxonomy lists referenced on the wiki are hosted by the groups that use their terms, and the wiki simply points to them

In an early demo I saw, Lisa asked why the implementer did not put aria-function on a contact us region.

<JF> if there is a possibility of re-use we should look at that/them, but if there is any confusion or concern of mis-sue we can mint a new value

LS: maybe we could use rel just for destination, but not for action.

<JF> so to answer Lisa's question, COGA could control their rel values

<Steve> Lisa_Seeman: is there an example of these 2 roles in use? Can't find in the demo code

RS: We have addressed large range of disability but not cognitive and cotnitive is a large number of people.

When doing aria 1.0, it was conscious decision , but painful one, to leav out cognitive.

we did not have a tf to do the research.

The screen reading and apis had already been quite mature at that point in time.

And, the a11y community had not yet been able to address interoperability at that time.

RS: it would be really bad to exclude the cognitive space at this point in time. Not in 1.1, but certainly in following versions.
... TF doing this work is raising issues to level we didn't have before.

This should be in a module to give COGA time to work out some issues.

To make this work well, we really need to work out out how personalization is done on the web.

Different cognitive disabilities have very different requirements.

One side is the metadata to annotate the content to make decisions, but the other side is how we match the adjustments to the specific user.

MC: WRT proliferation, we do not have to assume aria is the technology used to meet the requirements.
... John F said that a lot of this soulds like CSS to him.

<JF> +1 to Michael's point

Janina: Similar concern as Michael.

Little early to talk about specific solutions.

People need to get familiar with the problem space

What we really want people to understand the value of making these kind of changes.

This is a whole new space and we don't have a lot of background and we need time.

Leave the solution out and first map out the use cases, needs, ... do not start with solution and open that up for argument before we understand the space.

LS: I agree w/Michael, we do not have to assume solution is aria and not, say html5.

In the past, some of aria did migrate to html, and that was a very successful outcome.

I do not see a need for the community to wait more. We published research ages ago

We have proposed solutions, and that is what is creating the most engagement and discussion. I don't think we can wait.

Myfather is having difficulty operating a IOT HVAC system, even a care taker couldn't figure it out.

We need solutions now ... can't wait.

Bad consequence for real people now. Very real human cost happening now.

We can create the understanding in parallel with working on solutions.

Let's do that so we can discuss how it can be done better.

We need people in the w3c Wg who understand the user group.

So it is good COGA has a relationship with ARIA to work out the details of technical solutions.

<Zakim> MichaelC, you wanted to say we should find a mechanism to discuss feature proposals without raising ¨not in my language´s backyard¨ reactions and to say maybe just draft with a

<richardschwerdtfeger> q/

MC: I am amazed with how fast we got from the topic of use cases and started talking about how the markup is messy.

would like to spend more time talking about the use cases.

<Lisa_Seeman> +1 for michaels comment

When we have defined use cases, then we can start shopping for the right solutions.

<Steve> +1

<JF> +1

<joanie> +1

We can use a COGA- prefix on the proposals instead of ARIA-

<JF> +1 to using a coga prefix

<Zakim> JF, you wanted to comment remotely

<ayelet_seeman> +1

that way the solution in markup does not assume that ARIA is the solution.

<JF> I did

<mhakkinen> +1 to coga-*

<JF> i thingk it would also be useful to try and figure out which needs are addressed by metadata and then talk to metadata people, and for visual filtering, etc. we should talk to the CSS WG

<JF> I'd much prefer to see emergent solutions that weren't for disabilities only

<JF> while I am not in the room, I also like hearing creating anew coga prefix as a placeholder for now

MC: I think John's proposal is stage 2. Right now, we need to identify use cases and potential solutions.

<JF> tht prefix, for example, could be appeneded to metadata solutions, and that would be a possible solutiono to the @rel concern about Messines

Stage 2 is to shop around for solutions.

<JF> +1 MC

<JF> the progress seems to be happening in that direction

RS: Perhaps part of gap analysis is to define attributes and specify what they would do to support the use cases.

DD: I want to say I like the COGA- prefix and the idea we need to work for use cases.

I am not sure we wnat to spread the solutions around to too many different technologies. That could make it harder for the developer to put together a complete COGA solution. Be cautious of using too many technologies.

RS: Using a single prefix groups every thing together. That defines a space and can make it easier for authors to pull it all together.

Whatever we do, let's try to keep the concepts together in one space.

<Zakim> MichaelC, you wanted to say solutions for problems are already a hybrid of technologies, and anyway want to be agnostic to implementation, but also it´s an important message that

MC: It is already the case that a given problem is solved by multiple technologies. I want to be agnostic about where the solutions will land.

Do acknowledge that if we spread it out too much we could lose a thread. And, that has happened before.

Want to finish this segment of the agenda by going back to the use cases.

JW: If ARIA is a potential as a solution , we need the rationale for a single solution.

If personalization is employed, it can be a single solution. It has pay off of general interoperability.

If you tkae a different approach ... instead of deploying a generalized AT for people who need cognitive assistance,

but instead look at personalization in general, then it could start looking more like a media approach.

An aria attrib solution would be more assoicated with a single general tool whereas a personalization approach would fit a model where web apps adjust rather than AT making the adjustment.

So, the approach can effect how the implementation is realized and what its capabilities are.

LS: Semantics is just one part. Personalization is another part of the solution.

Another use case we have in mind is a help panel.

Another example for users is how to find the more options.

How do you discover new things. As people grow older, discovery is not longer as much fun.

Another aspect is the use of language.

EG, an attrib we propose is numberfree.

There is a disability related the to number processing.

For some people, numbers are a foreign language.

<richardschwerdtfeger> w?

Numberfree is a quick way of providing an alternative to numbers.

Then there is an opposite situation where some people understand numbers better than words.

Autistic sometimes have a hard time with medaphor or euphamism

COGA-literal would say to use precise meanings.

coga-explain and coga-feedback are 2 more cases.

coga-explain just helps give the user more information.

coga-feedback is a very important use case.

Sometimes people press send and nothing seems to ahppen, the mail jsut goes. people do not always understand so they send multiple times.

coga-feedbakc confirms that an action you performed really happened.

Sometimes the feedback may be spoken or it could be presented in print form.

It has been shown that it is really important to understand what has just taken place.

<Steve> is there an online agenda?

<Lisa_Seeman> <div>

<Lisa_Seeman> <span aria-alternative="easylang numberfree vocab1000" class="hidden">most people prefer simple text</span>

<Lisa_Seeman> In studies it was found that only 30% of users prefer long convoluted text with obtuse words and lots of numbers, with 56% claiming there preferred the simplified text , with the remainder unsure or stated it depends on the context

<Lisa_Seeman> </div>

LS: sometimes to help with language disabilities, you just need more or alternative content. This is coga-alternative.

Some users prefer long alt and some provide shorter.

With these attributes we cna provide many wyas to express the same thing, numberfree, alternative, literal, etc.

2 different ways to give alternatives.

coga-alternative can be complex text if needed. You can include as much information as is justified. and that can be complicated.

<ddahl_> if "coga-alternative" is an attribute, then it can't contain internal markup, which might be helpful

Another aspect of alternative can be symbols and pictures. Some people need pcics to aid understanding. And some people do better with symbols.

Instead of text supplementing an image, there are some who need images to supplement text.

Different tiers of images. P1 implies an alt that should be blank. P2 is an image that may supplement an entire paragraph. P3: there could images through a sentence.

There is a different between realistic images and symbolic images. And there are people who need one type vs the other.

coga-reminder can help specify how much prompting a person needs.

Some people need few because they are distracting and some people require more.

coga-distractions can specify things that may be distracting like animation.

But, for some people, animation could be helpful.

One orle suggestion if for keypoints.

Another could be for warnings.

Some of these could be part of dpub.

role warning could be used to call out warnings in ways to are tailored to different needs, e.g., have a special symbol or access key to find them.

<Zakim> joanie, you wanted to ask if coga-alternative and coga-concept are intended to replace content

JD: Would coga-concept and coga-alterntiave replace the content with something else?

RS: yes.

LS: coga-concept is really for symbol sets.

<mhakkinen> +q

Some people use symbols as there naturla language, e.g., in case of brain injury.

They may be very bright but the language part of the brain is impaired.

<jamesn> I just want to state my standard response when talking about personalization of things - how are we going to test everything? As soon as you have user personalizaztions you end up in a testing nightmare.

Janina: the is like braille a hundred years ago ... learned braille in one place you couldn't read it if it were generated in another.

<JF> +1 to jamesn comment

<mhakkinen> lisa, have you looked at the DIAGRAM content model, AKA diagrammar? I’m wondering if a nested structure of alternates a la diagrammar might be better and clearer

LS: I have not looked at that model.

<Lisa_Seeman> can u send me a link to e DIAGRAM content model, AKA diagrammar

<Lisa_Seeman> so i can look at it?

<mhakkinen> will do

<Zakim> MichaelC, you wanted to ask about next steps for ARIA WG

MC: Steer toward wrap up.
... We have ahad good review of use cases, but are deferring engineering of the specific solutions.

<mhakkinen> DIAGRAMMAR is at http://diagramcenter.org/standards-and-practices/content-model.html

MJanina: we have a lot of useful content, perhaps do another round of review, go to a note, and then start looking at solutions.

RS: It would be good to go back to the gap analysis and talk about how you are going to feel them and then come back for feedback.
... so far aria has not replaced content.

JD: I have a aria use case for replacement.

<Lisa_Seeman> aria-label replaces just in a diffrent modality

JD: The math example where they needed multiple ways to represent a formula. These would be replacements.

RS: would that go into the aria?

JD: I think it could be.
... from a functionality point of view, I see use cases for replacement.

RS: What we are syaing ... go back to gap analysis and look how to fill the gaps.

<mhakkinen> +q

LS: OK ... right now the gap analysis s spread across the papers.

So I get that; I ca put it togethr. I think we already have most of what need.

Maybe what needs to ahppen is people need to look at the issue papers.

JaJanina: it needs to be pulled together into a single document that we can publish as a w3c note. The issue papers are supporting information.

LS: OK, can do that.

RS: It needs to be distilled down so I can understand the issues and the solutions in a single resource.

So we can go to the community to figure out how to implement the solutions.

So, we are trying to both educate the community about the problem space and solve the problems.

<JF> Respectfully disagree with Rich that we need an issues + solutions paper at this time. Start with clearly defined issues and use-cases, and let's talk to our colleagues at W3C to develop solutions together

Janina: we need a COGA for dummies

<Steve> i suggest NOT using "coga for dummies"!!!!

<Steve> :)

RS: This is like the early days of ARIA. We need to avoid the kind of distractions like the early DTD arguments.

<Zakim> MichaelC, you wanted to say there are i18n issues to look at; overlaps with various technologies including ARIA, HTML, CSS, annotations; places where elements might serve better

Then we can figure out where the best place for each part of the solution is.

MC: I am not sure all of this goes in aria. Some is part of internationalization for example.

We do need to keep in mind debbie's caution about splitting things up too much.

Was not proposing that coga- would be used in the real world.

We should oppose that. We got forced there with aria-.

coga- is an experimental space.

In the real world, authros will not necessarily get all of this. and UAs will want to do some of it.

Are there ways we can simplify to get most of the benefit.

LS: thereare certainly some features that would be useed much more than others.

<jamesn> +1 to simplify. The less we put in the more chance that any of it gets implemented and used.

RS: a lot of good work to get it this far.

<Steve> yes thanks Lisa_Seeman !

LS: during the next f2f, could we have some COGA time.

CS: CSUN?

Janina: CSUN can be challenging. WCAG f2f?

Next year's f2f is portugal.

You may want your own coga f2f to pull this together.

MC: 2016 tpac is 11 months from now ... that is a long time from now.

MC/Janina/CS/RS: we need to work out some time

Sooner than a year from now.

Should it be closer to Europe.

What about ICCHP

in Austria.

that is in july

<Steve> we can talk with Klaus and Andrea re ICCHP -am sure would be good

Janina; want to come to tapc with note done, published and behind you. So july is a little late.

<mhakkinen> Authors can’t anticipate all the possible symbol representations a user may need/prefer. Is there any thought as to how a CogAT/UA would grab text, pass it off to a translator, and then replace the on screen text with the returned symbol string?

<mhakkinen> wanted to pose that issue.

<richardschwerdtfeger> Rich: Mark we are going to let the coga task force go back and do the engineering. If you could raise that with them it would be great

<richardschwerdtfeger> Rich: Coga people dropped off

<mhakkinen> ok

<jamesn> mhakkinen: couldn't you do that with a plugin anyway?

<Steve> thanks - for hosting us

<mhakkinen> that goes to the point of what users need and how it should get done. Why is it an author issue to provide the alternative markup.

http://rawgit.com/w3c/aria/mck_applicationRole/aria/aria.html#application

<joanie> scribe: joanie

Action-1361

action-1361

<trackbot> action-1361 -- Matthew King to Suggest new text for the application role -- due 2015-06-11 -- OPEN

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

MK: We have a branch link above.
... I made a post to the list yesterday.
... The post has what I actually did.

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-pfwg/2015Oct/0161.html

(RS reads from above)

MK: Application was previously a subclass of landmark; now it will be a subclass of structure.

(RS continues reading)

MK: If you first want to look at the application text....
... The definition is the first thing you (Rich) wanted me to change.
... It's actually similar to what Jason sugested; I just shortened it a bit.

RS: Actually that (what he just read) is not true.

MK: That paragraph is basically explaining why you might want that role.

(MK continues to present text to group)

MK: I want to scrap a paragraph that promotes putting the application role on the body tag.
... I don't want to prohibit it.
... But removing that paragraph means we won't be suggesting that.

RS: I'm concerned about the next one.

MK: Those two bullets are text from the original that I kept.
... I don't know if we need that either. We do have label required below.
... So I would be happy striking that text too.

RS: The title and label text?

MK: If you want to put application role on the body, how do you label it?
... Two weeks ago we agreed we would remove the requirement for document.

RS: If you have a slide viewer, you might not need a label on it.

MK: It would become invisible if it didn't have a label.
... You could just use roledescription.

RS: No one would see it, but...

MK: It's only there for ATs.
... But with label required true, I don't see what the bullets add.

RS: Agreed.

MK: Ok, I'll strike that too.
... The title being talked about here is not the title attribute; it's the title tag.
... I will strike everything from the note down.
... Is all the text above that ok now?

RS: Pending review from the group.

MK: Document is in the same branch.
... The first thing you'll notice is that it is a focusable child element of a widget or application widget.

<richardschwerdtfeger> http://rawgit.com/w3c/aria/mck_applicationRole/aria/aria.html#document

RS: Dialog is not a subclass of either.
... We use document in a dialog box.

MK: That's not needed.
... There is no need to put static content in a dialog and put role document on it.

RS: I would consider putting that in a test too.

MK: Widget is an abstract role. I don't think we want to have a context that has 30... I don't know how to write it....

RS: You could say "a role classified as a widget" or a "classified widget role, such as...."

MK: So the first change is to be explicit that you don't need to use document there.

RS: So it's redundant, but not broken.

MK: Correct.

(Group fades en masse and suggests resuming later)

MK: In HTML, there's no need to put role document on a body element.

RS: It defaults to that.

MK: And there's language in the spec that needs clean up.
... So I'm suggesting we delete everything in this description that...

RS: But if people are already doing it.

MK: It doesn't make it illegal.
... We'd just be removing text that might encourage authors to do it.

- DRAFT -

ARIA FtF Day 2

27 Oct 2015

Attendees

Contents

Script-based A11y

IndieUI

Action 1725 Article Feed

COGA taskforce interlock

Action-1361

Summary of Action Items

Scribe.perl diagnostic output