Meeting minutes
<JJ> Proposal during Summer season:
<JJ> 23 July - meeting
<JJ> 30 July - no meeting
<JJ> 6 August - no meeting
<JJ> 13 August - meeting
<GleidsonRamos> +1
<RacheleD> +1
<rachaely> +1
ACTION: Cancel meetings on 30 July / 6 August
<JJ> https://
ACTION: Look into adding css working group bot to #matf for automatically adding notes to GitHub
Page definition proposal
Two actions from last time to review
<JJ> New proposal: 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> Dialogs, modals, bottom sheets, navigation menus, and other similar user interface elements are components of a page but are not considered pages themselves. These elements depend on the underlying page for context and are part of the page's functionality rather than standalone navigational destinations.
<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.
Slightly modified Example 2 to "web components"
Updated Example 3 to "native components"
Joe_Humbert: Should we include bottomsheets as a page? In our company's app, a bottomsheet is like a modal and really is its own page. I'm concerned about how broad Note 1 is.
Joe_Humbert: Maybe it needs to be tweaked to include partial views
<JJ> Joe_Humbert: suggests: "Interface elements that rely on the underlaying page context" ?
rachaely: I mostly agree. The value of the page title is that the majority of the screen has changed
JJ: Maybe add a Note that it's a best practice to add title to modals
rachaely: Would it be more clear to say something about the amount of content on the screen changing
JJ: Might be a win for accessibility if they think they should add a title
Joe_Humbert: In Android and iOS "title" is part of the structure that should be provided
<JJ> for dialogs
Accessibility interface proposal
JJ: Please add thoughts on page to github. It's close to having a first definition that could work for the majority of mobile application cases.
<JJ> w3c/
<JJ> sub issue of: w3c/
JJ: Still some discussion whether "keyboard interface" is replaced with "accessibility interface"
<JJ> Proposed definition:
<JJ> accessibility interface
<JJ> interface used by assistive technology software to obtain semantic information about content and interact with mobile applications
<JJ> Note 1
<JJ> An accessibility interface allows assistive technology to access and interpret content even when the mobile application does not contain accessibility support
<JJ> Example
<JJ> A mobile application exposes its content through the platform's accessibility API (such as UIAccessibility on iOS or AccessibilityService on Android). Screen readers, voice control systems, and switch access software can all use this interface to obtain information about the application's content, structure, and state, enabling users to
<JJ> navigate and interact with the application through their preferred assistive technology.
<JJ> Note 2
<JJ> Operation of an application through a keyboard interface does not automatically qualify as operation through an accessibility interface, as keyboard interfaces focus on keystroke input while accessibility interfaces provide broader capabilities for assistive technology software.
JJ: "accessibility interface" can be used more broadly
Joe_Humbert: Do we need to broaden the first definition to "assistive technology software and settings"? There are settings in Android and iOS that aren't considered software.
JJ: Do we focus only on the interaction part or do we also want to emphasis the semantic information that can be obtained?
Joe_Humbert: I do think we should keep the semantic information in there.
ACTION: Attempt to make "assistive technology software" broader to make sure all types of assistive tech are included
rachaely: Is there a definition of assistive technology in WCAG?
<JJ> https://
<Joe_Humbert> https://
Joe_Humbert: Maybe we change it from "assistive technology software" to "assistive technology"
<Jamie> prsent+
ACTION: Change 'assistive technology software' (2x) to 'assistive technology' with link to definition
ACTION: Figure out where the accessibility interface definition should be used
JJ: We might need to change the definition of mobile context
1.3.3 Sensory Characteristics
<JJ> w3c/
JJ: Mostly came down to the addition of haptics
<JJ> Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, sound or haptics.
<Joe_Humbert> +1 to propsed change
<Jamie> +1
<JJ> Poll: do we accept the definition proposal?
<RacheleD> +1
<GleidsonRamos> +1
<rachaely> +1
<Joe_Humbert> +1
<Jamie> +1
<Carol> +1
ACTION: Accept proposal, add decision to group e-mail with option to block the decision
1.3.4 Orientation
<JJ> w3c/
JJ: Orientation was added to Draft in February then reopened
<JJ> Success Criterion 1.4.4 Orientation
<JJ> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4.
<JJ> Note 1
<JJ> Content that supports orientation changes must continue to meet all applicable success criteria in each supported orientation.
<JJ> Note 2
<JJ> It is considered a best practice to support all available orientations, such as as portrait, portrait (reversed), landscape, and landscape (reversed). Platform restrictions may limit available orientations for specific content types (such as video playback) or system-level functions.
JJ: There might be some platform restrictions with native components that would prevent supporting all orientations
<JJ> Poll: do we accept the definition proposal?
<RacheleD> +1
<Jamie> +1
<GleidsonRamos> +1
rachaely: I wanted to understand what our stance on reflow for mobile apps?
<JJ> 1.4.10: w3c/
<Joe_Humbert> 0 - i'm concerned that companies might take advantage of the last sentence in the second note, but I guess there is always the essential execption that they could try and use
<rachaely> +1
<Carol> +1
<JJ> Poll: Remove "Platform restrictions may limit available orientations for specific content types (such as video playback) or system-level functions."
<Jamie> +1
<Joe_Humbert> essential
<Joe_Humbert> if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
Joe_Humbert: WCAG 2.2 says "unless a specific display orientation is essential" do we need the second sentence?
rachaely: Some things like a video player may only support landscape, not portrait. Should that be a standalone note on its own? But that may be covered
<rachaely> +1
<RacheleD> +1
ACTION: Remove "Platform restrictions may limit available orientations for specific content types (such as video playback) or system-level functions." from note
<Carol> +1
<JJ> (potentially as separate note)
Joe_Humbert: I see some validity to keeping it but it should probably be a separate note
<Jamie> + Jamie
<Jamie> Zakim
<JJ> Thanks for scribing RacheleD
<Jamie> oops looks like I misspelled present :P