– DRAFT –
(MEETING TITLE)

Github for Success Criteria

JJ: Set up Github for Success Criteria. Sharing setup.

Repository named MATF.

JJ: Holds file for list of files for WCAG level A to map.

JJ: On the left hand side we have the markdown and on the right is on the rendered page.

JJ: Documenting insights for all the success criteria we have done so far.

Joe_Humbert: Question - will this appear in the content for each page? Should this be a GitHub issue and what we draft for mapping should be on the page instead? That's what is done in the AWG.

Joe_Humbert - that way we're not having direct conversations in the files.

JJ: Good point. Will look into other repositories.

hdv: I like GitHub, quite use to it. Some people find hard to work with, hit and miss. This way is quite flexible. This is what accessibility and performance task force is working.

<hdv> https://www.w3.org/WAI/ also has all of its content in Markdown files on GitHub

JJ: GitHub issues could be a way for to replace the comments in the excel

hdv: We can use issues for these meetings as well.

<hdv> [the github bot I mentioned lives here dbaron/wgmeeting-github-ircbot ]

Joe_Humbert - happy to create issues from comments over the next few weeks.

<hdv> [example of automatically posted minutes openui/open-ui#959 (comment)

1.4.13 Content on Hover or Focus

JJ: Interesting thing here is how we match pointer hover to apps when the main input is touch. Keyboard focus is less common and customizable on apps.

JJ: So far we've it as No as applicable to mobile web and mobile native.

JJ: Comment from Joe on the sheet: There is a long press gesture on both iOS and Android. This could become the equivalent of "hover". Apple did have 3D touch at one time, but abandoned it. They still control the IP for 3D touch so it could be used again

JJ: Should we say it's not applicable or it can be applicable with some adaptations?

audrey: I think it is still applicable with adaptations. I think it deserves some research in where it can be applicable and tested

JJ: Would people agree that long press is equivalent to hover.

audrey: Not sure if they're the same - long press is more I want to show something than hover.

<Jamers> +1 to Audrey

<Jamers> +1 to research and use cases across platforms

julianmka: I think there is a lot of similarity between what is revealed on long press and what is revealed on hover.

JJ: In web hover is usually to reveal tooltips, long press is usually to do an action.

Devanshu: Touch exploration setting should be explored.

Jamers: Has anyone tested tooltips on mobile web ? if that's a similar functionality with long press that is something worth thinking about

Joe_Humbert: In my company, for tooltips nothing appears on hover on focus, it has to be on tap or via keyboard key.

JJ: Perhaps we say "Yes" for applicable to mobile web.

JJ: Anyone connected there mouse to mobile device

Jamers: Yes, not sure how common the use case is for this as you've to put on assistive touch at the same time.

<Jamers> correction: assistive touch

Joe_Humbert: I've tried using a mouse in the past but it wouldn't work - without assistive touch

Thanks Jamers

Jamers: Works with assistive touch.

JJ: Be interesting if anyone can research long press versus hover for the next meeting.

2.4.1 Bypass Blocks

JJ: This is also an exception in section 508 and EN standards

JJ: Yes for applicable to mobile web, and Yes but different to web for applicable to mobile native.

JJ: Note from Joe: semantic markup, navigation methods (screen reader). We would need to push on google to provide better keyboard support a la iOS full keyboard access

JJ: Note form Alain: Should we also mention iOS containers

JJ: Apple does this in the navigation bar. But still not sure if you can jump via shortcuts from container to container

@JJ: In the discussion column: The Section 508 standards for software list as an exception.​​​​​​​​​​​​​​​ However can still be done and could be merit in doing so.

CC: We usually have tab bar navigations with 4-5 tabs for native and hamburger menus on mobile web. I don't think a bypass block is needed in those cases.

JJ: In native there is not much buttons in a navigation bar, and less tabs in a tab bar - less need to skip content.

Jamers: I'm looking at the WCAG content and it says "Small repeated sections such as individual words, phrases or single links are not considered blocks for the purposes of this provision."

<Joe_Humbert> https://www.w3.org/WAI/WCAG22/quickref/?showtechniques=241#bypass-blocks

Jamers: Native apps versus native screens conversations needs to happen.

<Jamers> set of native apps vs set of native app screens

Joe_Humbert: In the success criteria they have sufficient techniques that reference landmarks and headings.

JJ: Landmarks would be similar to containers

JJ: Frame techniques and hamburger menus would also apply to mobile web.

Jamers: Why are we not considering sets of native screens in the same way as web pages on a website?

JJ: I'm not sure either. We can get this as a topic for the next meetings.

<AlainVagner> a+

AlainVagner: For me this has strong impact on Multiple Ways. Multiple ways on a set of screens I get, but not so much a set of apps. So this could effect many criteria.

JJ: It will effect at least 4 success criteria.

JJ: Next meeting in 3 weeks

<Joe_Humbert> I will miss the first 2 weeks in June, but I will work on stuff offline

JJ: Nice to get feedback on GitHub and how we should use it. Will explore with more working groups on how they use it.