<Wilco> v
<scribe> scribe: trevor
<Wilco> https://github.com/w3c/wcag-act/pull/526/files
wilco: Didn't get any objects,
got a few +1s, this is accepted
... Need to ask AG about publishing
wilco: sent out recharter request to AG. mostly doing the same, big new thing would be introducing rules format 1.1
<Wilco> Define what types of implementations exist for ACT rules. Example: Is an implementation that reports only "cantTell" a consistent implementation?
<Wilco_> Work out how to write rules with subjective applicability. Example: How to write a rule that checks that visual headings have heading markup?
<Wilco_> Provide mechanisms to better incorporate state into ACT rules. Example: How to encourage consistent testing of hover and focus states for color contrast?
<Wilco_> Update the rules format with the latest ACT practices. Example: the new subsections in the rule's background.
<Wilco_> Improve options on accessibility requirements mapping Example: How could an ACT rule map to requirements with non-binary outcome ratings?
<Wilco_> Add considerations for machine learning. Example: Work out how implementations that recognize buttons based on styling with 90% accuracy can fit in with ACT.
wilco: 6 items above will be our focus for the updated format to 1.1
kathy: Any thoughts on how long to respond?
wilco: Usually within a week, so we should know soon
wilco: karen set the facilitators
a message that she was going to step back from the group for a
little while. Need to reassign her rule
... assigned to helen
... two surveys that are due next week.
wilco: PR for adding in link to
implementation app
... added a few assignees
... daniel opened #1802 for modifying expectation
... #1800 image name descriptive: improve examples still needs
one more review
... #1797 has 3 approvals, so good
... #1790 new rule from carlos that also deprecates several
others.
... pretty much done beyond that.
wilco: summary of our previous
discussion. Challenge is that iframes are implemented in
different ways by different browsers and AT. E.g., Firefox
makes iframes focusable, not a tabstop in other browsers.
... without an accessible name it basically becomes an empty
tab stop. Safari treats them as different regions, you have to
explicitly navigate into the frame
... suggests that iframes need an accessible name, but these
are non-standard things.
... if we care about supporting safari, need to consider that
aria-label and aria-labelledby are not supported on iframes.
Would need to use a title attribute
helen: Safari picks up title, but
others need the aria, iframes and svg. How much do we allow for
browsers having bugs if they are not following the
specification.
... not too sure about iframes, not really defined that
well.
wilco: This is not all that well defined. We talked about how different people test iframes.
kathy: Test if it has a non-negative tab index
wilco: What is the motivation for requiring iframes to have an accessible name. What criteria does it fail under?
kathy: Failed under 4.1.2
wilco: Is it a user interface component?
kathy: Its a container of
content, would require it when it is keyboard accessible. Need
a name when you land on it.
... allow aria-label due to accessible name computation.
wilco: Still focusable if you put
a role of none on it right?
... any scrollable container in firefox. Same with
role=presentation
kathy: Don't have anything to account for the role on the iframe yet
Daniel: Why to use accessible names? To label a region of the page?
wilco: No other landmark requires unique name or anything like that.
daniel: if you aren't providing any labelling fallback through a heading or something
wilco: Crux of the problem is if iframes are user interface components or regions
dmontalvo: iframes may be used to differentiate between regions
helen: If the AT do not notice it
at all, only if they are noticeable. Noticeable with the
tabstop
... often only asked to do one screen reader and browser
combination.
wilco: Doing JAWS with chrome you wouldn't fail it?
helen: Depends, but generally yes.
wilco: Two ways to look at this, suggest we treat it as a region so it doesn't need an accessible name or we know that some browsers that need an accessible name so we should always require.
thbrunet: Generally required it due to it messing up the frame list
wilco: But if you have 3 frames in your frame list without titles it isn't useful but isn't necessarily a failure of WCAG.
Will_C: Think we should focus on the impacted users
dmontalvo: Generally i use headings then regions and possibly frames, but if it doesn't exist it can be kind of confusing.
kathy: H64 technique for using title on frame and iframe elements
wilco: Since we think that
iframes need accessible names, at least in some cases.
... can write a rule that has a complicated accessibility
support.
Will_C: If the impact of adding this is very minimal, why not default to requiring it
wilco: We do because we don't want to overinterpret, since it doesn't follow WCAG.
helen: Would be helpful to find
the tech specs for working on iframe by the other groups
... think we should write a test for a title/aria-label on
iframe and svg.
wilco: Can go with that iframes
require an accessible name, follow the accessible name
computation even though there are known issues.
... what exceptions do we permit then?
... Have heard focusable, does role="none" make a difference
here?
helen: In some browsers the iframe is still focusable.
wilco: Arg for exception with role="none", had an objection when we didn't have role="none"
helen: They want that if it has role="none" it does not need the accessible name
wilco: If you have role="none" you don't want it treated as a region. Ex. Adding a third party form
thbrunet: Should be focusing or giving names to elements with role="none"
wilco: Big problem is how different implementations work
helen: Can we ask why firefox makes them focusable regardless?
wilco: They do that to make sure
certain controls are accessible, e.g., scroll bar
... negative tab-index removes it from all of its content,
which is really bad.
... my pitch: propose we allow iframes with role presentation
or none to not have an accessible name. Any objections?
helen: Is it worth sending this proposal to AG before we write the rule
wilco: I can take it to the person that objected to the previous version of the rule
<Wilco_> proposed RESOLUTION: Update iframe rule to allow no accessible name with role=none
kathy: Didn't we put a similar note on some other rule?
wilco: We have rules that fail
focusable controls for not having an accessible name.
... it may be inconsistent with what we have in other
rules.
kathy: I think I drafted something up in a PR about not putting role=presentation on a focusable element
wilco: This seems to be an inconsistency
<Helen> +1
<dmontalvo> +1
wilco: +1 if in favor -1 if continue to discuss
+1
<thbrunet> +1
<ToddL> +1
<dmontalvo> +1
RESOLUTION: Update iframe rule to allow no accessible name with role=none