Meeting minutes
Thank you quintinb
<quintinb> Haha, no, thank you!
Project planning -- taken up
<JJ> https://
JJ introduced project planning
@jj
JJ showcased the sections where all the issues are placed, and the overall structure
<Rob-W> The board is looking great, thanks to everyone who's put work into creating that
<Tim> I agree, looks great! Nice to have an overview like this
Jamie8: how do you want to assign these issue to the members in this meeting?
JJ we may have to create subgroups to work on grouo of issues
Page definition -- taken up
<JJ> https://
The team has agreed on the "page" as a common nomenclature
from Screen vs Page vs View
<pauljadam> got this out of ChatGPT: A page is a distinct section of an app that presents a specific set of content or functionality and is accessed through navigation. Each page focuses on a particular task or purpose, such as browsing items, editing a profile, or reviewing settings. Users move between pages to complete workflows or explore different parts of
<pauljadam> the app.
JJ shared the definition proposals.
We can start using "page" as a standard in out drafts
<pauljadam> dialogs are a part of a page but not a page
<pauljadam> just like the web
Aash: what about the bottomsheets or full size overlays, do they count as pages?
<pauljadam> dialogs are not pages
JJ: it depends on if it can be used as a standalone entity or depends on the underlying page
<pauljadam> the embedded resource thing does not seem necessary
<pauljadam> A page is a distinct part of an app focused on a specific task or content. Users navigate between pages to complete actions or access different features.
<pauljadam> ChatGPT shortened it :)
<Jamie> +1 pauljadam
<pauljadam> good idea on saying dialogs are part of the page but not a page
JJ we need to add examples as a note to explain what is a page and what is not a page
<pauljadam> navigation menus are not a page
Jamie: is this currently a placeholder or are we creating a working definition to be used?
JJ: Sicne we are in agreement to use "Page" and we will try our best to finalize the defintion today and only modify it IF needed
<pauljadam> In Atomic Design, the concept of a “Page” refers to the highest level of UI composition — it represents a fully assembled user interface that brings together all design elements in a real-world context.
ACTION: Add note or example emphasizing what would *not* be a page, e.g. a dialog, modal or navigation menu
<pauljadam> drop it
<pauljadam> drop embedded resource
<Jamie> +1 pauljadam
<quintinb> +1
<Aash> +1
<Tim> +1
ACTION: Drop 'embedded resource' from the definition text, maybe use something like: "A page is a distinct part of an app focused on a specific task or content. Users navigate between pages to complete actions or access different features."
<pauljadam> that sounds better than resource
<pauljadam> not sure if you need to say a page has a Page Title might be good
<pauljadam> and Pages need their Lang defined
<Jamie> and are parts of sets
<pauljadam> yeah distinct section or part is too generic
Tim: If we say distinct part, are modals not distict parts?
JJ it would not matter if someone treats modals as pages, except the title of the page part
<pauljadam> trying with ChatGPT to tweak: A page in an app presents content or functionality, must include a page title, and supports user navigation between different parts of the app. Dialogs are not considered pages.
JJ we can add a note about the modals in the defintion
<pauljadam> or how you access and open the dialog, if you go to the page first to open the dialog then the dialog is not a page, it's part of the page
A few modals can be opened from multiple pages. Example, add money to wallet in a superapp
<pauljadam> still they are part of those apges
<pauljadam> pages
<julianmka> modals can also look like pages at larger text sizes -- a shorter bottom sheet can take up the whole screen, for example
<Rob-W> Some modals can navigate to multiple screens within the modal
<pauljadam> multi page modal :)
<Aash> +1 julianmka
<Tim> we have to make that clear to people using our document for audits. I like the idea of adding this into a note.
<pauljadam> Mostly this definition is to determine what needs a page title
<pauljadam> the page needs a page title, the dialog needs a heading :)
Mobile operating system definition -- taken up
<JJ> https://
<pauljadam> guidance should be generic likely so it could be applied to any mobileOS, techniques could be specific to the code for each platform?
<pauljadam> Like how WCAG is generic but there are techniques for each technology like PDF, Flex, JavaScript, ARIA, HTML, Silverlight used to be there
JJ need to check if we can include Android and iOS in the title. How do we make it clear to people that this is our focus? also do we provide the guidance for other OS as well?
<pauljadam> Focus could be "mobile apps" if we need to cover more than just pure native, are we covering hybrid and web views inside native apps or not really talking about that?
<Tim> using the magic words "including but not limited to" ;)
JJ the focus is on the native part of it, but our scope includes web views
<pauljadam> text spacing I'm not sure if users really can adjust their CSS on mobile so easy?
pauljadam in the browser users can control CSS, but in Native, do they have any control?
JJ Hybrid apps might not be able to override the styling of the embedded pages
Keyboard interface definition
<JJ> https://
<quintinb> Except that joysticks are keyboard interfaces...
<JJ> w3c/
<pauljadam> I like the existing definition https://
<quintinb> Really worried about the direction of "I don't think x will work" - assistive technology can be strips of paper - what folks use as AT is not our remit
<Jamie> +1 pauljadam
<Jamie> +1 quintinb
<quintinb> Yeah I think keyboard interface applies as written for mobile too
quintinb joystick is a Dpad with LRUD controsl
JJ if we decide to split keyboard interface and Accessibility interface, how would this affect the success criteria?
JJ to figure out if any other definitions need attention
<quintinb> quintinb was here too