See also: IRC log
<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> <possibly other requirements after we clarify implications of this structure>
<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
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].
<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
<names names>
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/inclusion/exclusion from 1.0/ Succeeded: s/KeyEvent/KeyEvent properties/ Succeeded: s/KeyEvent/KeyboardEvent/g Succeeded: s/indepeendent/independent/ Succeeded: s/I´ve got ¨The properties of IndieUI request events must support certain properties of keyboard and mouse events and including relatedTarget, x, y, and others <need to specify>// Succeeded: s/Bianary/Binary/ Succeeded: s/A!!Y/A11Y/ Succeeded: s/It cant be useful in JS alone/It cant be useful in CSS alone/ Succeeded: s/leave out the controversial ones/return the others to the key-value pair approach/ Succeeded: s/Renior/Renoir/ Succeeded: s/scoping/scrollview/ Succeeded: s/preferenes/preferences/ Succeeded: s/thisl/this/ Found Scribe: jasonjgw Inferring ScribeNick: jasonjgw Found Scribe: Ryladog Inferring ScribeNick: Ryladog Found Scribe: MichaelC Inferring ScribeNick: MichaelC Scribes: jasonjgw, Ryladog, MichaelC ScribeNicks: jasonjgw, Ryladog, MichaelC WARNING: Replacing list of attendees. Old list: Janina_Sajka Michael_Cooper Jason_White Markus_Gylling Jeanne_Spellman Takeshi_Kurosawa Mary_Jo_Mueller James_Craig Katie_Haritos-Shea Kenny_Zhang New list: James_Craig Janina_Sajka Katie_Haritos-Shea Markus_Gylling Michael_Cooper Jason_White Kenny_Zhang @@ Cynthia_Shelly Renoir_Boulanger Lisa_Seeman Jeanne_Spellman_with_shopping Mary_Jo_Mueller_with_shopping Rich_Schwerdtfeger WARNING: Replacing list of attendees. Old list: James_Craig Janina_Sajka Katie_Haritos-Shea Markus_Gylling Michael_Cooper Jason_White Kenny_Zhang @@ Cynthia_Shelly Renoir_Boulanger Lisa_Seeman Jeanne_Spellman_with_shopping Mary_Jo_Mueller_with_shopping Rich_Schwerdtfeger New list: Yellow_river_2 Andy_Heath WARNING: Replacing list of attendees. Old list: Yellow_river_2 Andy_Heath New list: Yellow_river_2 Default Present: Yellow_river_2 Present: Yellow_river_2 WARNING: Fewer than 3 people found for Present list! Agenda: http://www.w3.org/WAI/IndieUI/wiki/Meetings/TPAC2013 Found Date: 15 Nov 2013 Guessing minutes URL: http://www.w3.org/2013/11/15-indie-ui-minutes.html People with action items: 57 cooper jcraig WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]