Meeting minutes
I have many regrets, but this meeting is not one of them, lol
2.4.2 Page Titled
<JJ> w3c/
<JJ> Proposal: This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.2 replacing “web pages” with “pages”.
<JJ> With this substitution, it would read:
<JJ> 2.4.2 Page Titled: Pages have titles that describe topic or purpose.
<JJ> Note:
<JJ> Limited screen space or technical limitations may make it impractical or impossible to display a visible page title on every page or to provide a programmatic title. Pages should therefore include whatever form of title or cue is feasible to support user orientation. This may be a visible page title, a programmatic title exposed to assistive
<JJ> technologies, or, where neither is technically possible, a visual cue that serves a similar purpose by helping users identify their current location within the application or set of pages.
Tanya Reading through previous comments, there are some sub tasks. I don't have a technical background to take components into account. I think in our draft we should be quite general. I was struggling with mapping page in this context because in a mobile app the flows are different from wrap pages, where it is uncommon to put a title on every
screen in a flow. What would be the page name of every part of a flow, and can headings fulfill this brief. It's important to acknowledge we can't have a full title on each part of a flow
<Zakim> quintinb, you wanted to would the title (if present) need to be marked as a heading?
<Rob-w> +1
I am not looking forward to the day mobile introduces heading levels...
<Jamie> +1 to adding page title content to heading SC
Rob-w iOS does support headings, but for user generated content not as a11y features, but they can be used for that
<Jamie> quintinb Swift UI already has heading levels
<shoobe01> +1 to comment "there is some text that has a heading role"
Rob-w I don't think a note is required to mark as a heading, it can be determined by something else. I don't see what adding a title to a nav bar would do for accessibility of an app
Joe_Humbert I think having some visual piece that serves as the title whether it's a heading or not is helpful. It's been there mostly in android + ios for a long time. Maybe Apple has reasons for it. While there isn't a title attributes for every component, alerts are an example, but while you can show an alert without a title, it's less helpful.
<Rob-w> I agree there must be a visual title. I'm just questioning if we need to say this should be in the nav bar.
<JJ> Android panes (alerts) a have title attribute e.g. https://
<Joe_Humbert> Rob-w understood. I think we should recommend it be in a consistent place if not specifically saying it should be in the nav bar or equivalent
Tanya I think it's important to look at the purpose of the criteria. It's about making the structure clearer to users - users need to find content and reorient themselves - for example for screen reader users need to know which page they're on. Sometimes when digging into an app, in rare cases, you don't know where you are, that is where this SC
applies
<Joe_Humbert> can you give examples of where it doesn't make sense Jamie?
Jamie I was thinking whether we should look into the words of the SC itself. Can we make it less complex, in past jobs this specific criteria hasn't been needed. Customers have struggled to meet this. We might need to answer if this a must or a should have criteria
'
<Rob-w> Full screen video?
Where there is no clear nav region, or in the context of a hybrid where you might have .... modals as well...
ACTION: Collect examples of titles used in apps e.g. alerts, navigation bar, etc.
ACTION: Collect examples of screens where it's not feasible to add a title
2.5.1 Pointer Gestures
*points at gestures
<JJ> https://
<JJ> correction: w3c/
ACTION: Approve w3c/
2.5.2 Pointer Cancellation
<JJ> https://
<JJ> https://
Joe_Humbert to review: Go to view files and then "submit review"
shoobe01 what if the app has a feature instead of is that kind of app - i.e. there is a drawing component as opposed to a drawing app
ACTION: For 2.5.2 replace "apps/applications" with "functionality" to apply to broader type of applications
Joe_Humbert This is why I am concerned about approving, because I have approval access and it get's merged
<Rob-w> I approve in principle, but can't hit approve on the machine I'm currently using.
2.5.3 Label in Name
<JJ> https://
<JJ> https://
Problematic for grouped complex components - thatr's why the label is abest practice
Joe_Humbert my concern with the second note is that developers may have a cop-out in terms of the rest of the visual text
quintinb shakes fist at not exposing all text to AT
ACTION: Change "Other visible text components *may*" to "must" in 2.5.3
Joe_Humbert can we make it "must" to ensure that visual text does need to be exposed
ACTION: Check if any SC will be failed if all visible text is not included in the label - e.g. only primary text
3.1.2 Language of Parts
shoobe01 you can set language? yes for the entire app.
ACTION: Process feedback for 3.1.2 and create Pull Request with Markdown file containing the proposed text
bye!
<Rob-w> Thanks JJ.