Meeting minutes
<jeroen> thnc
<jeroen> thnx
<JJ> move to the next agendum
Github Pages
<JJ> Github repo: w3c/
JJ - Overview of Github action workflow and how index.html file is deployed.
<JJ> Deploys at: https://
JJ - now we have something that we can share directly with world. Most guidance we have made is included. The goal is to align closely with WCAG2ICT
JJ - Can share with people in the future when we are ahead with the guidence
JJ - new 'meeting' label added to GitHub issues that will be discussed in meetings.
3.2.3 Consistent Navigation
JJ - WCAG2ICT replaces "set of web pages" with "a software program"
JJ - correction - EN 301 549 replaces "set of web pages" with "a software program"
JJ - This mostly related to how we replace "set of web pages".
<JJ> Mick: in our group we would look at a relatively small set of components for consistent navigations, such as search buttons?
JJ - I would consider a back button, close button, buttons in a list, a change of tab in a tab bar.
Aash - should we introduce certain things - the bottom sheets without the close button. Very hard to dismiss those overlays.
JJ - I think it would be interesting to add such things in a Note. That might be more related to Keyboard Operation rather than this success criterion
JJ - I wonder would a back button or close button placed differently would fail this criteria in app or is it too strict. Is it more about large lists of links rather than a single link/button.
JJ - Does 'navigational mechanisms' related to one button or link
Jamie - this criteria isn't about where the back button is on every app
ACTION: Define "navigational mechanisms"
Jamie - what are we considering navigational mechanisms? It would be helpful outlining examples.
JJ - this is specific to a single app.
3.2.4 Consistent Identification
JJ - WCAG2ICT set it to applies to a set of soft programs. EN standard set the scope from a “set of web pages” to "a software program".
JJ - 'same functionality' is pretty clear.
Jamie - Components and functionality are central to this criteria. The intent outlines that consistency extends to the text alternatives. Should we clarify exactly what is included?
JJ - It would be helpful to define if it's specific to component or user-interface components.
JJ - Is there any instance where a developer wouldn't be able to alter components. Such as if a user agent defines them.
<JJ> Mick: can't think of any reason why developers wouldn't be able to do this
JJ - we should have some note about this success criterion, and others related around the 'set of screens' and where hybrid relates. Would all views or screens in an app be included, regardless if they are a web or hybrid view.
JJ - I think that maybe in a screen or view we only consider the native app components. Maybe we exclude web.
Jamie - what would the logic be in excluding web views?
JJ - The EU standards exclude web views. WCAG itself would apply
Jamie - I can see as a task force that it's helpful to separate native and hybrid but with these success criteria it impacts the user's experience. If it's the same functionality it should be consistent regardless of the underlining code.
ACTION: For first draft, make first version of how we deal with hybrid apps and web content in apps
3.2.6 Consistent Help
JJ - EN 301 549 marked this success criterion is not applicable.
<JJ> https://
ACTION: Gather screenshots of help mechanisms in apps for next meeting
Jamie - be helpful to get examples of help mechanisms.
Mick - My understanding is this SC is only related to to if help mechanisms do exist on a view or screen, that they appear in the same relative programmatic order, it doesn't require them on multiple views.