Meeting minutes
So glad this has chatroom has a dark-ish mode
Welcome Steven
<JJ> shoobe010 introducing his background and work experience - a lot relates to mobile
<pauljadam> Welcome!
<JJ> move to the next agendum
Project planning update
@JJ You added "the"
<JJ> https://
JJ walking us through the board and the process.
Note the parent issue view where we can organise elements into "parents" and "children" to make more sense of grouping
Jamie encouraging everyone to go through some of the 108 unassigned tasks - to be actively moving things forward. Asking @JJ if there is a process. There are a lot of tasks available
JJ no process
<Jamie> 188 quintinb :P
Thanks - soz
<Zakim> quintinb, you wanted to do we take them out of the Todo lane?
How do we notice a good task to take next - what's the process? JJ says there are blocking issues - try to find blocking tasks and definitions to get things moving. Also look at small variation SC's. Also if you're into more difficult ones go for large / medium
<JJ> Blocking issues: https://
Jamie had a timed item that they'll take on for next time
Page definition poll
@JJ discussing using the start and end date to see if there are things that perhaps need some extra help
<JJ> Page definition: w3c/
<JJ> Page
<JJ> A page is a distinct part of a mobile application that presents specific content or functionality and is rendered together with its associated resources. Users navigate between pages to complete actions or access different features.
<JJ> NOTE 1
<JJ> Interface elements that rely on the underlying page for context (such as dialogs, modals, navigation menus, and similar components) are typically considered part of that page rather than standalone pages. However, interface elements that significantly change the majority of screen content or function as independent navigational destinations may
<JJ> be considered separate pages.
<JJ> EXAMPLE 1
<JJ> A native banking app's account overview screen that displays account balances, recent transactions and interactive charts. The screen includes native components for all interface elements, all rendered together as a single interface.
<JJ> EXAMPLE 2
<JJ> A mobile web banking app's account overview page that displays account balances, recent transactions and interactive charts. The page includes web components for all interface elements, all rendered together in the mobile browser.
<JJ> EXAMPLE 3
<JJ> A hybrid banking app's account overview screen that displays account balances, recent transactions and interactive charts. The screen includes native components for account balances and recent transactions, plus web components for interactive charts, all rendered together as a unified interface.
<JJ> Poll: Do we accept the Page definition proposal?
<quintinb> +1
<Jamie> +1
<pauljadam> +1
<Joe_Humbert> +1
<shoobe010> 0
ACTION: Accept page definition proposal
@JJ proposes that we accept - if there are any concerns please get them in sooner rather than later
Accessibility interface poll
<JJ> Where to use accessibility interface? w3c/
Please give a thumbs up / down on GH!
(GitHub)
2.5.1 Pointer Gestures proposal
<JJ> Proposed definition for 2.5.1 Pointer Gestures
<JJ> All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
<JJ> Note 1
<JJ> This requirement applies to mobile applications that interpret pointer actions (i.e., this does not apply to actions that are required to operate the platform software, operating system, or assistive technology). Each layer is responsible for its own pointer actions only, not for those in an underlying layer.
<JJ> Note 2
<JJ> Path-based gestures are gestures that depend on the path of movement, not just the start and end points. Examples of path-based gestures include swiping through carousels where the direction of interaction matters, sliders dependent on the direction of interaction, and custom drawing or pattern gestures. Simple actions like basic scrolling,
<JJ> single taps, or standard platform gestures (such as pull-to-refresh) are not considered path-based gestures.
@JJ can we execute this action or is there more to consider?
<JJ> (copy/pasted note has changed slightly in version of July 23rd)
Joe_Humbert Do notes 1 and 2 need tweaking? Is platform software different from platform accessibility features?
<shoobe012> Computer failed overall, just catching back up.
@JJ does the scrolling action in a scrollview count as a layer? Do we need more examples
Joe_Humbert is the mention of layer helpful? Is that common language?
<Jamie> agreed with Joe_Humbert on his questions.
pauljadam the part about assistive touch seems strange. There's nothing about that in the success criteria? Does that absolve the developer from supporting it?
pauljadam we're just doing developer guidance - the developers need to add extra. This note creates an exception
pauljadam this note may be overly repetitive
<JJ> Keep or remove note 3?
<pauljadam> remove
remove
<Jamie> 0
<shoobe012> 0
<Joe_Humbert> 0
2.5.2 Pointer Cancellation proposal
<JJ> github.com/w3c/matf/issues/38
<JJ> Newest proposal: w3c/
<JJ> Proposed definition for 2.5.2 Pointer Cancellation
<JJ> For functionality that can be operated using a single pointer, at least one of the following is true:
<JJ> No Down-Event
<JJ> The down-event of the pointer is not used to execute any part of the function;
<JJ> Abort or Undo
<JJ> Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
<JJ> Up Reversal
<JJ> The up-event reverses any outcome of the preceding down-event;
<JJ> Essential
<JJ> Completing the function on the down-event is essential.
<JJ> Note 1
<JJ> This requirement applies to mobile applications that interpret pointer actions (i.e., this does not apply to actions that are required to operate the platform software, operating system, or assistive technology). Each layer is responsible for its own pointer actions only, not for those in an underlying layer.
<JJ> Note 2
<JJ> Functions that emulate a keyboard or numeric keypad key press are considered essential.
<JJ> Example
<JJ> Examples of essential functionality include features required for meeting system requirements (such as waking a device from sleep, power management controls, and emergency functions).
pauljadam is this the layer part? Or is this the notes?
<pauljadam> I think the layer part os confusing
<pauljadam> is
JJ layers are added in WCAG2ICT
Joe_Humbert after reading through some of these. It might apply to closed source applications like kiosks.
Joe_Humbert perhaps layer is not necessary for us
<pauljadam> I think folks are confused on what user agent means so that could be clarified rather than talking about layers?
<JJ> WCAG2ICT editor's draft: https://
<shoobe012> pauljadam +1 for definitions. We just did a page def. Do we need more unique defs?
Layer is not defined in WCAG2ICT even though it's introduced there: https://
<JJ> User Agent draft: w3c/
<JJ> pauljadam
pauljadam I think when you're applying wcag to mobile user agent is more confusing. What is the user agent, the OS? What worries me is that assistive technology is a user agent, I think it's something that loads the page
<Joe_Humbert> is there a pure native app? I mean one with nmo webviews?
Joe_Humbert I added assistive technology (AT) because it's "any software the retrieves and presents content"
pauljadam the browser retries the web page
*retrieves (soz)]
pauljadam for an AT to be a user agent we'd need something like VoiceOver without Safari
Joe_Humbert this is why I left it in. It's because WCAG 2.2 does reference AT as a User Agent
pauljadam They "help"
pauljadam I've never seen AT that retrieves and renders content
Joe_Humbert we'd need to ask why it was there
2.5.3 Label in Name proposal
@quintinb leveled up typing skills!
<JJ> Latest draft: w3c/
<JJ> New draft will be proposed 20 August: w3c/
<Jamie> @quintonb super typer
<Jamie> quintinbnb super typer
:D
<Jamie> quintinb
Planning discussion
<JJ> we also need to go through feedback from First Public Working Draft to make sure its all addressed before a new publication
Jamie Having a proposed milestone date could be helpful for planning backwards. We have several items ready for publication, but I would think that having a date to get something out (e.g. end of October) - one of the things that might help is setting a date could get use there. Even working backwards from a date could help. Having an idea of
timeline for the defintions would help us move things to done. And it could help us identify where we need more people involved. I think everyone can contribute and we understand time frames. Having a timeframe is a good starting point.
@JJ will check in with Tania when she's back
Bye bye!