Independent User Interface Task Force Teleconference -- 15 Nov 2013

<trackbot> Date: 15 November 2013

<MichaelC> meeting: IndieUI FtF Day 2

<jasonjgw> scribe: jasonjgw

<jcraig> Is the first note under 3.3.3 clear?

Michael queries whether the target of the zoom or pan request events can be the screen (as well as objects).

James clarifies: pan moves the canvas; move moves the object on the canvas.

Michael suggests adding an introductory paragraph to the spec for each of these eventsw.

Michael moved to 3.4; he quotes his proposed requirement.

James suggests that the requirement specifically refer to custom scroll views.

3.5 UIValueChange request.

James clarifies that this is for custom fields that need to be set to specific values by the user.

Michael: provide a mechanism to adjust numeric values of custom range controls by small and large increments.

Michael (following clarification): minimum or maximum values.

Michael: section 4 - feature detection.

<jcraig> ACTION: jcraig to clarify in events spec that ValueChangeRequest is specific to custom numeric range widgets [recorded in http://www.w3.org/2013/11/15-indie-ui-minutes.html#action01]

<trackbot> Created ACTION-73 - Clarify in events spec that valuechangerequest is specific to custom numeric range widgets [on James Craig - due 2013-11-22].

James: provide a mechanism so that authors can determine whether any given UI event is implemented by the ua.

Michael: we have identified all of the requirements inherent in the spec; next we need to look at the requirements proposed in the wiki.

James suggests the action list as a source of requirements.

Janina recommends starting there.

<jcraig> https://www.w3.org/WAI/IndieUI/track/products/2

Michael clarifies (responding to a question from James) that post-1.0 requirements should be documented somewhere. The details of how to publish will be worked out later, but it's helpful to identify all of them.

James: the concept of a secondary action (triggered, e.g., by right-click events, with/without modifier keys etc.), have been proposed.
... context menu is the most common secondary action.

Michael formulates the requirement.

James: issue to coordinate with Web Apps working group.

Janina: we're doing that already.

Michael: proposes closing issue 5.

<MichaelC> close issue-5

<trackbot> Closed issue-5.

James and Michael defer issue 7 for now.

James: media controls (actions 16, 17, 19, 20).

Michael: provide a way to access standard media controls - he formulates the proposal to capture this idea.

James and Michael clarify the list of media controls proposed.

They opt to mention minimum/maximum volume volume specifically as these are distinct from mute/unmute.

James (responding to Michael): suspend/resume needs clarification - may not be media-related.

Michael: provide a mechanism to suspend/resume an activity might be the requirement.

James notes that mute/unmute/volume can be accomplished by system-level controls and don't need cooperation from the application.

<jcraig> Would like to push 17, 19, and 20 to "future release"

<dsinger> action-25?

<trackbot> action-25 -- James Craig to Add markRequest with variant properties indicating "fromLast" (like Shift+click or select range from last mark) and "retainMarks" (like Mac Cmd+click or Win Ctrl+click meaning select in addition to) -- due 2012-11-09 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/25

James: queries whether suspend/resume and volume should be deferred to post-1.0.

Janina suggests deferring them beyond 1.0.

It is proposed to re-categorize the issues in the issue tracker accordingly.

Michael clarifies that the Indie-UI events apply to technologies other than HTML 5 media elements.

James notes that if you're using HTML 5 audio/video, these events aren't needed, but if you're doing custom rendering of the video controls etc., then the new events would be required.

James: next/previous track are not proposed for exclusion from 1.0.

Michael: action 25 - mark request.

James: this is for marking/selecting an object, then performing an action on it, e.g., deletion. Drag and drop is one presentation of a variety of underlying operations. It can be analysed in terms of the concept of selecting something, then performing an action on whatever has been selected. Selection of multiple objects is the general case of this operation.

James would like to see this in 1.0.

He notes that there is inconsistency among operating systems as to the keyboard bindings of these operations.

Michael: action 53 - an activate request event to augment default action trigger.

James: example use case: slider on lock screen of a mobile device - the gesture to unlock the screen shouldn't be treated as an activation/click event.

Michael: queries what the requirement is.

James clarifies that it's the equivalent of a DOM activate event - also equivalent to click, which serves as the de facto activate event.

In some cases, it has been suggested, a click event isn't appropriate - using it would result in behaviour which is undesirable.

James: example - a slide to unlock gesture in a Web application.

Michael notes that the DOM activate event has been deprecated; this proposal would resurrect it and would require coordination.

James notes that there is a clear use case and that the click event should normally be used - this proposal applies where click is manifestly inappropriate.

James and Janina concur: this one is a candidate for 1.0.

<scribe> ACTION: 57 to help and main focus requests. [recorded in http://www.w3.org/2013/11/15-indie-ui-minutes.html#action02]

<trackbot> Error finding '57'. You can review and register nicknames at <http://www.w3.org/WAI/IndieUI/track/users>.

James: this is the issue discussed yesterday, including the question then considered of landmark navigation.

Michael adds this issue to his note from the discussion yesterday.

James: the "main" item is subsumed by the larger proposal for events that can move to landmark regions (as defined by ARIA landmark roles).

Jason suggests documenting "main" as a proposal under discussion, in the context of the alternative proposal to the generalized navigation to landmark regions proposal.

James and Katie clarify that the "invoke help" event can be invoked by a gesture in user interfaces that support 3d gestural input.

Action 58 - point-of-regard focus and blur.

<trackbot> Error finding '58'. You can review and register nicknames at <http://www.w3.org/WAI/IndieUI/track/users>.

James clarifies that this is separate from the "return to previous point of regard" proposal discussed yesterday.

James clarifies that this is a UI event, not a request event.

Michael: the event reacts to gain or loss of point of regard.

James notes his search for a better term than "point of regard".

Janina notes that there currently aren't any good alternative terms currently proposed.

James: for post-1.0 - text editing events - issue 9.
... search for the next heading/occurrence of a search string, etc., in applications where te entire document is not loaded into the DOM tree of the ua. For performance reasons, often only part of a document is loaded (e.g., by editors).
... manipulation of size - resize the requests in graphics applications.

Michael captures the requirement.

James: changing the centre point of a rotation event should also be included here.

Action 31 - column sorting events.

<trackbot> Error finding '31'. You can review and register nicknames at <http://www.w3.org/WAI/IndieUI/track/users>.

In grids (i.e., interactive grids rather than static tables) there are sometimes commands to sort a column in the current sort order - this is typically implemented in the visual interface by clicking on the column header.

James and Katie clarify that this could (but probably doesn't) have applications in mobile devices, since presumably the headers should still be presented after scrolling and hence should be available for clicking in the visual interface.

Michael turns to the wiki and the requirements proposed there.

<MichaelC> Events Requirements wiki

Notification event requirements - it is agreed that this is not clear as expressed in the wiki. It's very confusing, as James suggests.

Michael suggests this isn't a requirement on Indie-UI events, but may be a requirement on implementations.

Multi-input requirement: Michael and Jason concur that this is evident from the broad goals of the specification.

Michael suggests treating these as broad objectives rather than requirements and that they could usefully be added to the introduction.

Jason concurs.

Michael summarizes the remaining items.

There is discussion of implicit and explicit point of regard in the case of manipulating images on screen.

<jcraig> Point of Regard will always be an explicit Element.

<jcraig> But if there is a mouse event, there will be coordinates on the Event object.

Michael notes that some of this material could be valuable in an authoring guide in addition to the introduction.

Michael proposes to move this text to another wiki page.

<jcraig> Keyboard triggered events will not have the optional x/y so the web application would need to determine appropriate x/y coords, e.g. the centerpoint of a zoomable view.

The last item also fits into the category of being destined for the (as yet hypothetical) authoring guide.

<MichaelC> Wiki page for Events Authoring Guide

<Zakim> jcraig, you wanted to discuss MouseEvent, KeyboardEvent inheritance

<jcraig> UIRequestEvent should contain a superset of MouseEvent and KeyboardEvent properties

Michael (clarifying a point developed by James): UIRequestEvent must support both keyboard and mouse properties.

James clarifies that other events may need to be included in this.

Michael reformulates the requirement accordingly.

<jcraig> https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#constructor-mouseevent

<jcraig> https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#constructor-keyboardevent

Michael proposes to work through the scenarios to determine whether and to what extent these are the scenarios that we want to inform our requirements for version 1.0.

It is proposed to discuss the Indie-UI/Epub relationship after the break, then return to scenarios.

<MichaelC> Michael´s notes on Events requirements walk-through

<MichaelC> Events Requirements

<MichaelC> 1.2 Goals

<MichaelC> Provide an API layer to define user intended events that is agnostic of the specific input methodology and independent of a user's particular platform, hardware, locale, and preferences.

<MichaelC> Allow the API to support user commands without requiring specific physical events.

<MichaelC> 1.3 Scope

<MichaelC> Do not require specific physical user interactions (keyboard combinations, gestures, speech, etc.) to trigger particular IndieUI events.

<MichaelC> 1.5 Backwards Compatibility

<MichaelC> Structure the events such that they are only triggered if the application registers an interest in them, to optimize performance and allow backwards compatibility.

<MichaelC> Provide a way for applications to communicate that a given event request was or was not handled so the host OS or UA can attempt fallback behaviour.

<MichaelC> Do not block standard events when listening for IndieUI events. ISSUE-15 may impact this.

<MichaelC> Provide a way to "reset" ui-actions on descendant node. ISSUE-15 may impact this.

<MichaelC> 2. UI Actions

<MichaelC> Allow event delegation without affecting performance and scoping of events. ISSUE-16 impacts this.

<MichaelC> 3. UI Request Events

<MichaelC> There will be a requirement for how IndieUI events fit in with the order of other events ISSUE-15

<MichaelC> Might need a requirement to be able to associate an IndieUI event with other related physical events ISSUE-15

<MichaelC> 3.1 UIRequestEvent

<MichaelC> IndieUI Events must extend UIEvents unless the IndieUI requirements are met directly in UI Events.

<MichaelC> IndieUI must support the following functions unless supported by other technologies: undo, redo, expand, collapse, dismiss, delete, move, pan, rotation, scroll, valuechange, zoom

<MichaelC> The properties of IndieUI request events must be a superset of the events from at least both keyboard and mouse events in the UI Events specification.

<MichaelC> 3.2 UIFocusRequestEvent

<MichaelC> Support linear navigation for first, previous, next, and last.

<MichaelC> Support directional navigation for (8 cardinal direction).

<MichaelC> Provide a mechanism for users to move focus non-linearly to other sections of the document such as toolbar, palette, and windows. Action-57: also help (main covered by landmark)

<MichaelC> Provide a way to navigate amongst landmark regions. This may be at risk in 1.0 and could be pushed to future version. Might be a11y specific.

<MichaelC> Provide a way for users to return to their previous point of regard, like emacs and vid and IDEs support. This does not have consensus yet. Need to determine if it is just keyboard or others as well. Could be pushed to future version. Seems to have general use cases.

<MichaelC> ===============

<MichaelC> 3.3 UIManipulationRequestEvent

<MichaelC> Provide a mechanism to move, pan, rotate, and zoom objects or the screen.

<MichaelC> 3.4 UIScrollRequestRequestEvent

<MichaelC> Provide a mechanism for custom scroll views to scroll the view by increments, entire screens, and to the limit in four cardinal directions.

<MichaelC> 3.5 UIValueChangeRequestEvent

<MichaelC> Provide a mechanism to adjust numeric values of custom range controls by small and large increments, or to minimum and maximum values.

<MichaelC> 4 Feature Detection

<MichaelC> Provide a mechanism for content authors to determine if the user agent has support for specific events.

<MichaelC> Requirements from tracker http://www.w3.org/WAI/IndieUI/track/products/2

<MichaelC> Provide a mechanism to access context menus and perhaps other secondary actions (might be future requirement). (issue-3)

<MichaelC> Provide a mechanism for standard media controls including play, pause, stop, fast forward, rewind, move to start or end, increase or decrease volume, set volume to minimum or maximum, mute and unmute, move to next and previous track (action-16, action-19, action-20) (some of these might be future)

<MichaelC> Provide a mechanism to suspend or resume an activity (action-17) (might be future)

<MichaelC> Provide a mechanism to select one or more objects (contiguously or discontiguously) for the purpose of performing an action (action-25).

<MichaelC> Provide a mechanism to activate an object without implying a click event; scenario is slide to unlock screen on FirefoxOS (action-53) need to coordinate with Webapps

<MichaelC> Provide an event that reacts to gain or loss of point of regard (action-58) @@still need a better name for POR

<MichaelC> Future requirements http://www.w3.org/WAI/IndieUI/track/products/4

<MichaelC> Provide a mechanism to support text editing (need to spell out specific events required): (issue 9)

<MichaelC> Provide a mechanism to support quick search functionality directly within the web application (issue-12)

<MichaelC> Provide a mechanism to resize objects in graphical editing applications with ability to constrain proportions (action-26)

<MichaelC> Provide a mechanism to set the centerpoint of a rotation request (action-26)

<MichaelC> Provide a mechanism to request grid sort by columns (action-31)

<Ryladog> scribe: Ryladog

IndieUI and EPub

MG: DPIG for ePub
... This functionality is more than A11Y and user preferences
... Let us have a formal meeting for Indie-UI and DPIG
... We will be happy work with you. Use cases that I will describe to be sure Epub and IndieUi intersections is
... We want to sure we understand each others scope
... I have read Latest Working Draft of IndieUI. There i a higher level preference model that I do NOT see in IndieUI
... 1. eBooks come in multiple renditions (dual rendership, highly graphical - fix layout - just an image - image centric HTML - lots of layout and design)
... 2. Mainly a textual rendition
... the selection of hese two come from what devoce is recieving, not the user
... The user can state a reference on a much more abstract level

<mgylling> http://www.a11ymetadata.org/the-specification/

MG: AccessMode property is not stable yet, but what they have is so high level, this mode is auditory, etc
... the equiv in Schema.org is contnet properties - so shoul InideuI have a similar preference model
... Another point is Image description stuff (info graphics in image repositirties)
... My preference would be that I would prefer a imagal respresentation

JW: What is in scope for User Context module is still open to discussion - if think people working on ePub might like to utilize IndieUI your group could influence our direction related to n& P oresented to the user
... We welcome that participation

MG: This higher level is NOT out of scope for Indie-UI. This seems to be very different in what I currenty see in you rspec

MC: It is in scope maybe for version 2 but possibly sooner
... so ePub will neeed to provide you with clear use cases

MG: I see that you are looking at MediaQueires - which I think is right. But I have a question...??
... I am curious about document object and CSS independent
... theere is this undrlying idea that ypu should be able to send these stand alone datasets

JC: The MQ are up for debate - some in CSS spec - several preps related to a11y metadata project (key value pair UI).
... The IndieUI and A11Y metadata specs are sort of getting to the same point

JS: I think Markus is giving us a wider view than just accessibility for Indeie-Ui and ePub

JC: Search via IndieUI context I will increase the search result with captions the AT, web page to determine th project - but use meatadat project to determine WHAY resources is more relevant for that search

<Zakim> jcraig, you wanted to mention I'm not sure UIRequestEvent will be a direct superset of MouseEvent and KeyboardEvent. Instead it may be implemented more like inherited from UIEvent,

MJ: Yes - not overlap for IndieUI and A11Y metadata - there is a functionality match.
... Currently in IndieUI we hae a list of atomic properties - very low level building blocks
... But we also need a higher level abstract peference

<Zakim> jcraig, you wanted to mention I'm not sure UIRequestEvent will be a direct superset of MouseEvent and KeyboardEvent. Instead it may be implemented more like inherited from UIEvent,

JW: Pleasse dont assume the current working draft is anything finalized at all
... In response to James the UC to supply the infor thwn used by search tools to use matching MD that corresponds to the users preferences - that is the righr way to think about this relationship
... MQ there is the question whos spec should it belong in CSS, or Indie UI? Also a question odf syntax and API
... Use extend MQ syntax UI to adopt and extend it for purposes of specificying the Inie UI UC props for the CSS WG
... These are the two questions

JC: I was misunderstanding your questions. Now I understand, relative to the user context
... for 1.0 for scope are things that can be expreseede through brwosers currently
... or a higher level I prefer tacile we are need to hold on until UA catch up - but that is hwere we will be going
... This is important for adoption

MG: Line height - but not line length? why?
... This is important for dislexia - but I am sure that you have thought abourt this

JC: Yes we did. Users can do that with user stylesheets
... We can expose the defaults today -
... then if you get systems that allow you to set CSS vehicles then that would be good

MG: Another UP prop is queries for out of line accessible deacriptions is maybe the same answer James?

JC: Like i prefer spanish over english? Browser can do that already
... there is a lang in CSS
... via cpntent negotaipn
... Langiage overarching prefs not common that you would serve all content to all users to a device

MG: No we would not want to but renditions being embedded in the same package - peoepl may want to in the future for the language but another example is to target different agegroups
... Allow runtime negotiaition for simple language renditions

<jcraig> for 1.0

JW: Intent by IndieUI to confine UC props ti current UA - we may not all agree n that yet

<jcraig> My statement was about the 1.0 release…

JW: We want to push the UAs with our properties if we can, in my opinion
... We have discussed how specific these props should be

LS: For langauage - As skills change you would want the content to change - that should ship in the same eBook
... We have book that is in enlish as your skills in a new language improve to be able to graduate

KHS: I think all languages referenced in an eBook SHOULD be loaded with that book

MG: Teachers are looking to adapt contect to individual students cleverly to your knowledge level and prefence
... we want o allow for these things, age range, skill range, grade in mathematcis
... Do i need to take a simpleversion of this exersize
... I know that we need to get to 1.0

KHS: We should reference LMS, A11Y metadata, Schema.org, spec that have worked for years

MG: loet talk low haning fruits. Will you address high contrast prefence - maybe we should not do that in MediaQuesries after all

Renior: Some MediaQueries have a limitation it is bianary - the device supports it or not

JC: I would object that it is on or off or binary setting. MD has options not on or off

MC: MediaQuesries is Binary

CS: MS has 3 options

JC: There are 3 props in our spec, usercolor, seerbackground color, and??
... With all of those three MS can get all they need to implement and others as well

JS \: I agree but lets not get stuck in the weeds

<jcraig> Microsoft's proposal for -ms-high-contrast is very specific to Microsoft's implementation.

<renoirb> Low hanging fruit is definitely the way to go :)

MG: James high contrast will be using Media Queries?

<jcraig> I think it can be solved in a cross-platform means with three queries for display-contrast-increased: %, user-color, and user-background-color

JC: All three are used in Indie UI props
... Black on white you would get different color values there - with MS it would be a 100% but other platforms would be a percentage value

MG: I did not see the contrast increase - but now I see it
... The other issue is ambient audio. The ability to HOH to surpress background audio

JS: That is a good one, in HTML5 A11Y TF we have the clean Audio requirements

MG: Yes, but there is a mainsteam use case for people to add a background sound to run while reading a book

JW: Audio Contrast

<Zakim> jcraig, you wanted to mention http://dev.w3.org/csswg/mediaqueries4/#mf-environment

MG: Contrast between control of both or having it turned off or on

JC: I just posted this in CSS which currently only has one property about ambient light - so maye we need the same for audio

JC: There is a note using this working with MS - you can tell that the CSS WG is thinking about some of this. Ambient audio as well - up until now CSS WG has seemed to object to ambient audio - but may be open if we are not exposing privacy issses and is implementable as well

Rich: I do not understand why CSS would not want to have the ability to turn off BG audio

JC: Because it is not something that can be adjusted with out JS
... I am not soeaking for them

Rich: Markus what if we were able to adhist the volumn of the BG sound - we could put a value in there?

MG: Yes so what Jason said is ghaing both cases, on/off and then control of level

JC: Did you get what I said about audio?
... It cant be useful in CSS alone

Rich: We are going to having multipe UIs which will be annoying

JC: I want to leave the non controvesial ones for MQ in and return the others to the key-value pair approach - and do it in IndieUI

JW: Rich point if we are going to have two different UIs - MQ and IndieUI - then will the queries allow finding both?
... We have not settled if we want two seperate interfaces -as the issues are similar

MG: In terms of what Jason said that sound nice to me.

JC: That is what I have in mind - we just talked to CSS WG a few days ago
... I want to reassure Renoir that it can be accessed

Renoir: I agree we are producing the strle sheetand modifying the user preference

Renior: As a designer I want to change the video and view
... We need to know what kind of events and preps and how deep we go with them
... A user may already articluate that in their OS

<jcraig> It's only been a couple days since we talked to CSS and WebApps, but the plan now is to bring back the key/value pair accessor un the UserSettings interface <https://dvcs.w3.org/hg/IndieUI/raw-file/6644d04a01df/src/indie-ui-context.html#UserSettings> and allow all keys to be accessed that way. And also to allow a subset of those prefs to be exposed as CSS-style media queries.

Renior: there was Pink on Pink - we are about to reproduce that and I do not think that is the right thing to do

JS: User Context, Markus what do you think about IndieUI Events spec?

MG: eBooks are now massively interactive - we would like DPIG to review IndieUI Events spec
... Pagination and you have next and prev

JS: More hieracrhical support?

MG: Yes

JC: next and prev would work in the scrollview and there is also a page slider at the bottom of eBook readers that could be used to respond to the next prev

<jcraig> The "pages" scrollview could respond to the equivalent of a pageup/pagedown event, and the slider that controls the scrollview could respond to value increment/decrement.

LS: The results that are going to come from the CognTF you might want to think about how cognitive is going to plug-in
... I know that IndieUi has said that Cogn is out of scope at this point - you are really going to have to think about where this is going to plug in as we move along

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/6644d04a01df/src/indie-ui-context.html#UserSettings

JC: our planis very extensibale - this is the part that is coming bac in
... These key pairs can be exposed ti address anything that you want
... That is something that could/will be done in IndieUI for Cognitive impairments

<renoirb> e.g. window.preferences = {contrast: true}

JC: I have been pushing back for now because there is nit current support in UAs - but ot is NOT off the table
... We have to limit scope for 1.0 to get it adopted
... We are NOT ignoring Cogn please know that

JS: Maybe we need a modular approach, as we try to boil the ocean
... Thank you Markus we seriously appreciate your input and joining us

Rich: This is a design goal - take the luminosity thing

JC: There is with in MQ to extend the general JS UI

<jcraig> window.matchMedia('(luminosity)').addListener('myLuminosityChangeHandler');

<jcraig> window.matchMedia('(luminosity)').addListener(myLuminosityChangeHandler);

<jcraig> planning to add:

JC: The idea for this second one - I am going to add something like this for existing one that we speced as the UI

<jcraig> window.settings.addListener('fontSize', handler)

JC: I will not be able to come back after lunch - then we should do it now

Rich: I also will not be able to return

JW: For Michael, what Rich said is a UC req that props are updated that needs to go in the reqs somewhere

BREAK: return at 1:30

<MichaelC> ACTION: cooper to incorporate 14 and 15 November 2013 FtF Events requirements decisions into wiki [recorded in http://www.w3.org/2013/11/15-indie-ui-minutes.html#action03]

<trackbot> Created ACTION-74 - Incorporate 14 and 15 november 2013 ftf events requirements decisions into wiki [on Michael Cooper - due 2013-11-22].

User Context Requirements

<andy> Good Afternoon China, Good Evening/Good Morning the rest of the world

ah: reading minutes, sounds in tune with conversations I´ve been having over past day

<andy> http://www.w3.org/WAI/IndieUI/wiki/User_Context/Requirements

ah: have updated user context requirements wiki

gathered from yesterday´s discussion that accessmode stuff wouldn´t make it into version 1

we´ve been working on this in access for all for a long time

accessmode was our best take on what was needed

accessforall3

has two parts: metadata and preferences

preferences came here

and metadata went to schema.org

at that point they matched

now they´re diverging

idea in access4all3 was to have minimal metadata

people aren´t gonna do it

so it´s scaffolding

what we provide, make it simple as possible

one issue is author intent with metadata

was posting a video, trying to annotate if was usable w/o captions or w/o video channel

in access4all3 decided not to tackle author intent

much of the info you want comes from context

so usefulness of modalities can vary

there are two kinds of stuff

@@ stuff

and @@ other stuff

nobody yet talks about accessmode

when you look at preferences you see relationships between bits

modeling those relationships is difficult

in part because of author intent

for how e.g., captions might be used, how the relate to the other stuff

in 24 7 5 1 we got it wrong

we used a tree, but it´s not hierarchical

and didn´t adapt well to context

so we took that into account for access4all3

accessmode is the core, as simple as possible

doesn´t express anything that might vary with context

all in access4all3 agreed on this

then took out to a11y metadata people

access feature

at 11th hour and 59th minute

dissent came from people who hadn´t been involved in the original access4all discussions

about how the relationships between terms and author intentions are expressed

e.g., if you have captions for video, how to express that they replace auditory content, whether they´re necessary, etc.

view of access4all3 people is this needs to be determined by search engines at index time

so we don´t try to express relationships, let search engines figure it out

though we don´t know what all can be figured out automatically

different search engines might do it different ways

which could lead to a competitive marketplace for this information

so we just expressed the access modes and left the rest

access4all3 people believe we should retain accessmode but not express relationships

the question is when and how to do that

my own view is plug it in and see what search engines can do

there are a host of preferences related to accessmode

auditory replaced by text

which could be captions, transcript, alt text

don´t know whether accessmode will make it into version 1 of epub3

gather some questions open

so have stuck with low hanging fruit features

but I believe accessmode should be retained

we might want to tackle question of where things come out of accessmode

though could leave to search engines

so what I´ve done to user context requirements

have put in space for all the accessmode ones

but not filled them in yet

one way it does relate to relationships

is that you can have combinations of modalities

lots of combos possible

have included ones I think are useful

there could be others

right now they´re organized around preferences

not sorted between requirements, use cases, scenarios

<andy> http://www.a11ymetadata.org/the-specification/

organized according to the organization of above resource

text on visual is extremely common, e.g., text rendered in an image

road signs, other stuff

or math in image

e.g., charts, chemical diagrams

using images instead of canonical representations

need some intelligence

e.g., if don´t have text alternative for image but have some other alternative, might be useful to provide

also can express that information in the resource depends on color perception

can express as preference that you need color independent resources

so system wouldn´t send you the color dependent version

acccess feature @@ a11y metadata @@ changed from .6 to .7

some of the access features done in the legacy stuff

<andy> http://www.w3.org/WAI/IndieUI/wiki/User_Context/Requirements

mc: we´ll need to convert this to scenarios and requirements

and decide which ones are 1.0 and which ater

based on a reasonable metric

also the lots of thinking that went into that, need to find ways of getting others on board without repeating years of discussion

ah: have tried to put some background in the wiki

would like to provide full documentation for all this now

even if they will be met in later versions

mc: that´s ok as long as we don´t distract from the process of getting to 1.0 on reasonable timeline

ah: think you need the information to make good triaging decisions

so would like to keep working on that

also looking at epub3 stuff that can´t be done with access mode

timeline of the next several weeks

matching up the various preferences will be a reasonably constrained editing job

mc: propose this work be done over the next several weeks and we take this up at beginning of new year

ah: can have done sooner, but ok with that timeline

js: had a lot of movement on Events and want to keep that moving now

and then pick up in January

jgw: so you´re proposing to take various sets of preferences and match them up and see what´s missing?

ah: yes

think there is a requirements job

from my perspective, a requirement is a preference

not falling on my sword for the timeline of implementing a particular one

but want to have them all written down

jgw: makes sense

I can help but not in next several weeks

ah: great

<andy> Ryladog: I would suggest Madeleine Rothberg

mc: agree with identifying a full set of requirements

we might find some are met elsewhere

which affects which we decide to meet ourselves when

js: @@

ah: on the wiki I mention some of the existing mappings

jgw: I heard James proposing we´d have our own system of key value pairs

and API

some of which reachable via media queries

don´t fully understand what that means

e.g., if CSS uninterested, do we get to extend?

regarding what are the raw properties

good that we´re looking at art from related communities

then question of determining what properties we want to have

think we agree that UAs have to populate from legitimate data sources

anything we require of UAs needs to make its way through the W3C process with implementation experience requirements

so we have to work out with the UAs what´s reasonable

ah: we´re not docmenting metadata properties, we´re documenting preferences

sometimes I´m proposing preferences that match metadata

maybe that´s not the way to go, need to explore

there are various ways to get preferences in and out

e.g., personal style sheet, others

would be useful for someone to list what the mechanisms might be

mc: always thought we were just proposing a specific output method

but have seen recently that there might be more

in which case reviewing the possibilities would be good

js: also thought was just one until this week

ah: maybe so but should consider the possibilities

jgw: do people agree browser should decide where to get data from?

jeanne: essential for future proofing

cs: if you tried to spec, would get push-back from browsers

ah: <static>

<Jeanne> http://www.w3.org/TR/UAAG20/#gl-store-prefs

<Jeanne> User style sheets <- http://www.w3.org/TR/UAAG20/#gl-style-sheets-config

Independent User Interface Task Force Teleconference

15 Nov 2013

Attendees

Contents

IndieUI and EPub

User Context Requirements

Summary of Action Items

Scribe.perl diagnostic output