Wilco: Next week is axe con and CSUN - conferences, and several people have conflicts. So agreed there will be no meeting. Pick up the next meeting on March 24th.
<Wilco> scribe: JenniferC
<Wilco> https://github.com/w3c/wcag-act-rules/pull/85
Wilco: I have two updates I want to share with the group. First, I have been working on an update to the directory structure, this moves things around quite significantly but wanted to ensure test cases show up and can be linked to. This problem have been resolved. But second change - the URLs are going to change. I'm going to have the ID of the rule in the URL, so if the filename needs to change, we don't have to change the URL anymore
<Wilco> act/rules/zoom-text-no-overflow-clipping-59br37 => act/rules/59br37
Wilco: Example is this URL regarding Zoom Text. The URL is a lot simpler.
<Wilco> https://deploy-preview-86--wai-wcag-act-rules.netlify.app/standards-guidelines/act/rules/
Wilco: Another thing to share:
Shawn Henry and Steve are looking for a design change. Here is
the preview URL.
... EOWG is making changes to the design. On the WCAG 2 Test
Rules page, there are design changes at the top, within the
blue background - a larger header with more links inside. And
on the side, the rules themselves have the content on the
side.
Trevor: The design seems a little bit empty.
Kathy: I'm ok with it. It says
"WCAG test rules" at the top and this is written other places,
so it feels a bit repetitive.
... In the light blue area, there is a repetitive title of "All
Test Rules".
Wilco: The blue area just has
text in it. The navigation used to have an "About the rules"
page - it's no longer in the horizontal navigation area (light
blue). It just has the text "All Test Rules" in it. All of the
links are in the header above (darker blue area).
... There is the content that says, "For developers of
evaluation tools and methodologies". It does not mention that
this is also for accessibility experts.
Daniel: Maybe this can be rewritten.
<Wilco> https://www.w3.org/WAI/standards-guidelines/act/rules/
Daniel: We seem to be marking a difference between tools and tests for methodologies and I understand if the group feels like there should be no distinction - and include accessibility experts in it.
Kathy: Is EO trying to make a distinction about 'who this page is for' on other pages as well?
Daniel: I am not sure. But this is a good suggestion, I will make a note.
Tom: The page content is indented at the top in the heading is not aligned. Doesn't seem a rhyme or reason for this.
Daniel: I think this is the new redesign and it's very new (as of two hours ago).
Wilco: I have the feedback I
need. Daniel, do you have time to capture the feedback here
from this meeting?
... Never mind, I will find some time to write up the feedback
today.
Wilco: I was not there for
planning on this update. Kathy, Daniel, is there anything new?
I have not had a response yet. But I wanted to pitch something
to this group. There is an Evaluation Tools list, which is
managed by EO. I was wondering if this group would be
interested in taking over maintenance for this
product/project.
... It may be appropriate for the ACT Task Force to manage this
list.
<Wilco> https://www.w3.org/WAI/ER/tools/
Daniel: I am not sure but it may be specified as a project under EO. It would be good to confirm at project management level as to the reason this work is with EO.
Wilco: After the redesign project is over, should we ask that we take the lead on maintaining the Evaluation Tools list. Given that there are tool developers in the ACT Task Force.
Tom: Is there a plan regarding tools that are not taking up ACT? There are some more informal test tools on the list.
Wilco: Understood and they would stay on the list.
Trevor: It's possible the list has old tools.
Wilco: It's a valid point that the tools list may be ancient. So maintenance is important.
Trevor: I saw that some tools that are not relevant to ACT on there.
Kathy: It says there are 19 tools that provide accessibility information, but there are over 100+ tools on the list. Are you thinking of managing the list overall? I am wondering, would we primarily going through the list to say, these are obsolete, not longer available, etc. - those related to accessibility. And for tools that are not related to accessibility, someone can evaluate and research those as well to see if they are still rel[CUT]
Wilco: I will start talking to the EO and AG chairs.
Zakim take up next
Wilco: There is one comment from
Helen, who isn't here. So there isn't much to discuss. There is
also one more deprecated rule, which I will put on my
list.
... Thanks to everyone for filling out the survey. I saw seven
responses which is sufficient, so didn't complete the survey
myself. There is a rejection for the ARIA-hidden rule, from
Tom, where the state change is called out on this rule. But not
others.
Tom: Yes, it seemed strange that it was called out in this rule specifically.
Wilco: If you have a modal, and you move the focus away, the modal is dismissed. This is what I understand about this example. Maybe the assumption is just too broad for this rule. I agree that the assumption is true anywhere and we can make this less general.
Kathy: Generally, when we write the rules, when ARIA-hidden is 'true' - but this rule has the assumption that aria-hidden is not true. I don't think we spell that out in other rules.
Wilco: Should we update this rule to say it is only relevant to those elements that are focused. It doesn't occur until the focus? Is that a direction to explore? That's why this is written as an assumption.
Tom: Typically focus isn't changed.
Wilco: I think it's a reasonable
assumption. So let's see if we can re-write the assumption to
be less generic. Is that a reasonable resolution for everyone?
Ok, writing that down and moving on.
... Next comments. All of these are about example 4 and 5 so
let's look at those as they're important. Pass example has an
on focus attribute on a link, immediately redirects the focus
to an input element. I think this was added to highlight a
focus trap on modals, but maybe this doesn't describe that
well.
Tom: As long as you send focus somewhere else, it was acceptable. I saw that in the requirements in the rule. In the fourth rule of ARIA use.
Wilco: I don't know or think that Passed Example 4 is a realistic scenario, looks like the problem it's trying to solve. How do other people feel?
Trevor: Where did this come from?
Wilco: There was an event listener there that redirected it to the modal.
Trevor: Is that too complex to put into this example?
Tom: Yes, it is in the focusable definition.
Wilco: Do we all want to see a better example here?
Kathy: The reason I had problems with it is that it doesn't have an accessible name, and it's a 'pass' example? Maybe if there is a better explanation of why this one is here.
Wilco: Agreed. Pass Example 4 is not clear, and need more explanation.
Tom: The challenge we always had was that so many analytics tools, they flag every element on the page.
Wilco: This becomes effectively impossible to test. That's the reality of it, though. If there are real-world examples, we should be including them.
Tom: Should this be in an assumption? Agree if it's real-world
Wilco: This example came up in a
tool that I've experienced.
... But this example is not the way you would solve for it, so
I think we should update the example.
... Let's move to Example 5. I don't think this fails WCAG. The
button element is focusable because the tabindex="-1". Using
VoiceOver, you can still get to this content. But it's why it's
here you can click on the thing, have it be in focus, but
there's no control. But then, it's not a button anymore, only a
text node because you put "aria hidden" around it.
Kathy: So, if you can click on it with a mouse still, you can still activate it?
Trevor: It's still possible to put programmatic focus on it...
Wilco: Then it's programmatically hidden, it doesn't have a role, there's no node in the a11y tree, and you can't tab to it. Surely there are scenarios where this could be a problem, but I don't feel this definitely is, or I couldn't find a way for this to be a problem.
Tom: Trying to think of a scenario - i.e. a toolbar in Word, where you can still interact with it...
Wilco: Yes, you could have a
script that provides that interaction. This again, we do see
this kind of example with modals. And the button is solvable by
putting 'disabled' on it... but you can't do this type of thing
with links. If you want it to be avoided as clickable, you can
give work through CSS. I don't see a problem with it if it's
not sequential navigation. I see the Zoom text argument, but
not a strong enough case to say thi[CUT]
... There are other contexts related to it.
... Who thinks this needs to fail WCAG?
Kathy: Are you saying it isn't a failure because it has the tabindex of -1?
Wilco: I am saying it may not. If this is obscured by a modal overlay that prevents clicking, apart from the mark-up, then it's not a failure. But that's not mentioned here.
Trevor: While there could be problems, if the developer fixed this in the wild, I wouldn't immediately think of someone with AT doing everything they can do access this / blow up this.
Wilco: Thanks, we'll take it up next week.