<Jennie> scribe: Jennie
<Detlev> I would consider meeting in EU
<Chuck> +1, but not sure I'm attending.
+1 if arranged soon, so I have time to get permission to go
<alastairc> Interested in a separate meeting from CSUN?
<Rachael> +1 but funding trave is always a challenge
<Justine> +1 but not sure about feasibility of attendance
<Brooks> +1 to CSUN meetup
Rachael: the advantage of CSUN is
we are already there
... it is a benefit to get together because we get a lot
done.
Alastair: I may be able to host but this may not make it easier for anyone in the U.S.
<Fazio> +1 to Rachael
Alastair: funding may be an issue
for people.
... it can be tricky to have people in multiple locations but
it may be better to have a dedicated day or two
... a completely virtual conference
... could you block off a couple of days?
<Rachael> +1
<Chuck> +1 would love to (even expect to) if I get permission to go.
Most likely +1 but it depends on when.
Chuck: my +1 is face to face
<stevelee> +1 remoting to a f2f is always hard work
Michael: multiple people at different locations has been tried in the past, but proved difficult.
Alastair: I will discuss with Michael and Andrew on Thursday.
Michael: I think the Silver task force wants to meet at CSUN anyways.
Alastair: yes, and that is
probably the priority.
... if you have any other ideas, please share on the list.
Alastair: this one was not
discussed at TPAC.
... a few negative comments came in.
... Bruce thought it should be a new success criteria.
... was skeptical about the testing aspect.
... I have not found the testing difficult.
Brooks: I'm not sure I totally
understand the implications. From a practical standpoint, how
are we going to train our QA teams to do the testing.
... narrowing of the view point in the browser...the logistical
details. I'm not sure if it is scoped in a way that allows it
to be understandable and efficient.
Alastair: In practice our testing
is generally: take a browser, have a resize button. For me, you
would check if there was a loss of functionality as you move
down to that point.
... for the things we look at, it wouldn't be that tricky for
us.
... the reason we didn't do it previously was because we had
some concerns about people with legacy sites that didn't work
at all sizes.
... I'm struggling to think of any of our clients that have
that kind of set up anymore.
... Has anyone else had that kind of experience?
... ok. Andrew had similar testability concerns. Kim had
thought we were not changing existing SCs at all.
<Detlev> voted on Reflow - in line with my earlier approval
Alastair: we have been generally
adding success criteria rather than editing them, but it could
be possible to do a modification to 2.1
... is that because you do testing of sites and no one has had
trouble with the inbetween states?
Detlev: we usually flag that, and
say it is formally met at different widths. It works, we still
flag it as an issue.
... I think Patrick has mentioned the potential to just meet it
at this one point, and not meet it at other points. I don't see
any harm extending it across the entire range.
... because users will zoom in, and if there are things
disappearing, it will be a real issue. I think it is a good
thing to catch.
Rachael: I do some testing on government sites, and they do have this issue with reflow. The shift in the wording is not going to affect what they have to do.
Alastair: not the in between bit making it harder, it is doing it at all?
Rachael: exactly.
Alastair: it is rare for there to
be issues with the in between points. It is also rare-ish to
want to have an exception in between.
... we have niche conditions on either side of the
argument.
... for those that are skeptical, we need to take it to the
next stage.
... we need practical examples, practical testing.
... this is the last one of our initial reviews. I think it is
the nature of the concerns, seems to be around testing, and the
practical aspects.
... I think we should test those practical aspects.
... we don't have to resolve anything for this one. Any other
questions or comments?
Alastair: timeline in the
spreadsheet is week by week up to the recommendation stage for
WCAG 2.2 which is scheduled for October 2020.
... 1st wide review is March 2020, which doesn't give us a lot
of time.
... we have many scheduled in already. Thanks to COGA and
Rachael for working on most of those.
... we are trying to plan out when the reviews. I'm hoping we
will have a few weeks of near final reviews before the final
drafts.
... I have emailed all the authors.
... for anyone that has not responded yet, I will be getting
back in touch again.
... any questions on our current project plan and review
sequence?
... these are not set in stone. If you are not going to be
there one week, please let me know and we can shuffle things
around.
Alastair: this is the next up on the new success criteria.
<alastairc> https://www.w3.org/2002/09/wbs/35422/focus-vis-enh-acceptance/results
(without ") https://www.w3.org/2002/09/wbs/35422/focus-vis-enh-acceptance/
Alastair: 1st question: does the
text meet the requirements?
... people generally think these are met.
... Detlev says the text is not easy to grasp.
... this came up partly because it was not covered as
effectively as we wanted in 2.1
... from looking into it more, it would have been more
difficult because of adjacent colors.
... we really needed a new way of defining the physical
part.
... there were 3 main visual things.
...1: how different is the contrast before focus.
...2: how big is the change of contrast.
...3: an adjacency factor. If you put a dark outline around a
dark object it is not as easy to see as a light one.
... we want it to contrast with the control, or be
thicker.
... the approach seems to be reasonable.
... in terms of defining it as a minimum baseline for 2.2, it
seems like a reasonable approach.
... Detlev, is there a way to make it easier?
... those that managed to get to the Understanding Document
thought it was ok.
... I added a bit which should be highlighted as a
suggestion.
... people were happy with the techniques. We already had one
from David MacDonald.
... we can point to some examples where it does work.
... proposal and next steps: some happy to accept, some
editorial suggestions from Bruce.
... I have incorporated those into the working document.
Detlev: would it make sense to
add an invert contrast type technique?
... inverting foreground and background. It is a bit crude, but
it would meet this, correct?
Alastair: yes.
... there are probably quite a few techniques we could add
which are fairly general.
... any other questions, comments, objections?
... ok.
<alastairc> https://alastairc.uk/tests/wcag22-examples/focus-visible-enh-examples.html
Alastair: if you do think of
anything later, I did a set of examples.
... slides, tabs
... a good page to start off with.
... it is a good exercise to see if a site you use would pass
those indicators. If you find good examples, please send them
in.
Detlev: that's a nice selection of examples.
Katie: yes, they are great, thank you.
Alastair: if no objections, can we resolve to accept this into editor's draft?
<Detlev> +1 for adding
<Ryladog> +1
<laura> +1
Brooks: I have a question.
... when the focus visible enhanced would be required.
... there is no exception for using browser defaults?
Alastair: in the 1st couple of
examples, you can see how varied it can be between
browsers.
... this was one of the problems we had. It was very sticky,
tricky, as to whether changing the background behind a
button.
... it was a bigger loop hole than we were comfortable
with.
Brooks: so relying on the browser default visible indicator is not going to cut it.
Alastair: this one comes in at AA.
Brooks: I will have to custom style every focus indicator on every page?
Alastair: it does depend on your
conformance statements.
... if you are doing Windows based browsers only, with a white
background, you would be fine.
... if you have a consistent background, you would only need
one focus style.
... one example had every area had its own focus style.
Brooks: I have some practical
concerns in terms of development time, and testing.
... I think it would be important to consider the time it would
take content authors to design and vet their designs.
... I would like to have more discussion on this topic before
passing it through the editor's draft.
Alastair: ok. In my experience,
our clients have already been defining focus styles.
... it has generally been a matter of getting them to do it
well.
Brooks: I have worked with a lot
of clients too, and this has not been my experience.
... design considerations as well as testing.
... it is not that I am opposed to it, but want to look and see
how much extra time this may add.
Alastair: ok, well, I am happy to open that up. Does anyone else have similar concerns?
Katie: Since we were not able to
get things to work properly through the browser requirements,
and that something specific has to be the background
... it is important to see where we can go with this.
... we will be putting this out for public comment, and at that
time we can get a bigger feel for how big a lift it is.
... I think the comments will be good.
Alastair: in editor's draft
doesn't mean it is in, it means we are happy for it to go to
wider review.
... Brooks - if you have examples where it may be difficult, it
would be good to find out about that. Describing the scenario
where it may be difficult to change the outline.
... I did have discussions with GDS in the UK, and after
non-text contrast I had extensive conversations with
them.
... they are working with hundreds of departments, and have a
components library.
... they have to do a lot of work to apply the intent. They
went through that, and have done it,
... and in my opinion, when you are working on a significant
scale, once it is in place it is quite straight forward.
... I do appreciate getting there can be a big ask.
... anyone else have questions or comments?
Mike: I think that Brooks is
right - this will be some effort for teams.
... even if theoretically orgs settle on a design pattern set,
teams have variations.
... it will affect the dev cycle. There won't be a way of
automatically testing it.
... some effort will be required.
... I think it is a worthy thing to put in front of people, but
will have a fair impact on some teams.
Alastair: in terms of getting it
in front of people, getting it into the editor's draft will do
this.
... any objection to taking it to the next step? Once in the
editor's draft it will be open to comments in github.
Mike: will this have to be met by a team in all different themes?
<jon_avila> Perhaps the question is about consistency across focus indicators.
Alastair: it is the same thing as
color contrast.
... anyone else have thoughts on that?
Katie: it is kind of unusual. It
has to be available on every location.
... I think that means, by default, all of the content would
need to meet this requirement.
... But, it being something you turn on or turn off would be a
different story.
... all content would need to be able to meet this, if we are
going the per page route.
Alastair: yes, I think it comes
down to the usual conformance we have regarding page variations
and that sort of thing.
... any other comments?
... ok.
... let's keep it in the schedule for next week, but I will
line up a second success criteria for next week.
Alastair: Rachael has been working on with the COGA task force. Looks like less people have gotten to this one.
<Rachael> Examples at: https://docs.google.com/document/d/1lUh2ZsQXRlC_S2gtJE5mMSIHEwB1K2gBBc0VL3hL4Yk/edit
<alastairc> For main navigation as well as controls needed to initiate, progress or complete a process, at least one of the following is true:
<alastairc> 1) a mechanism is available to ensure is visible without scrolling or interaction when it is possible to progress,
<alastairc> 2) the importance of the control can be programmatically determined;
Alastair: Bruce's comments were around how the importance of the control was defined.
<Rachael> Document: https://docs.google.com/document/d/1DPtCqWHjrhj3QZ4afsqzmWDd-zMSf39RsMqSpR2QGCg/edit
Alastair: I had slightly other
suggestions.
... Rachael, have you had a chance to look through those?
Rachael: I am doing that now.
Alastair: my main concern is
catching pages or sites which are not necessarily a
problem.
... e.g. a registration form has many buttons off screen which
would fail.
... you could put the button at the top, or make it sticky, but
I have noticed usability issues with people pressing it too
soon.
... which is worse? Not having the button on the screen, or
having them not notice the button.
<Fazio> hitting button too early
Fazio: if you show a button, it
is an indicator that it needs to be pressed.
... don't show it unless it is ready to be utilized.
Alastair: yes, Microsoft used to have this pattern
Rachael: I think there are 2
points of confusion. I don't have a good suggestion.
...1: the save button or whatever it is having to be visible at
the initiation of the process.
<Fazio> showing a buttonI think this is a good COGA sc
Rachael: the button of the
control vs the hamburger
... the examples I have pulled show the intent, but I don't
have good wording to solve it.
... if the submit button does not have to be visible until
ready, does that address your concern?
Alastair: sort of.
... Depending on how people fill in the form, when you fill in
the last input, you may not have that button in view
... if you have a moderately long form, you might not have that
last button in view while completing the last input.
Rachael: I have had trouble finding a form where that is
<Rachael> https://docs.google.com/document/d/1lUh2ZsQXRlC_S2gtJE5mMSIHEwB1K2gBBc0VL3hL4Yk/edit
Rachael: I moved the example
up
... the example should be open to you now
... in the mobile version, they broke it down into small
pieces.
... in this case, they changed the form so you only see 2-3
items before you get the next action. That is one possible
solution.
... if you scroll down to #7, Craig's list
... what is interesting there is based on the spacing, continue
may or may not show up based on the radio button you
select.
... where you run into the problems is where you have optional
or very long fields.
... some of this is layout, some is spacing. There is the need
to mark it up with the alternative.
... the importance.
<Zakim> mbgower, you wanted to say it is also not clear how required versus unrequired fields relate
Mike: 1st: there are lots of
scenarios where there may only be a few required fields.
... it is not clear to me how this will interact in a situation
like that.
... at that point of time do you have to be near the
parameter?
...2nd: it doesn't really seem to accommodate low vision at
all. It appears to assume an unzoomed page.
... with minimum level of magnification, sometimes a button is
no longer present in a specific view port.
... I don't see that this in the current form is considering
that for low vision users.
Alastair: I'm trying to
understand/imagine how that would pose an issue.
... example 2
... it is a form that reflows, transforms as you go.
Mike: in this specific one, if there are no situations where a user uses magnification and reflow which triggers a new format, that's true.
Alastair: to go back to Rachael's
response, using the importance option is a solution, that feels
like what people will rely on.
... is this success criteria needed, or could we bring it into
information and relationships.
... marking up navigation using some of the language from the
success criteria.
... adding marking things with the importance attribute
Mike: getting back to my first point. It is possible to progress as soon as you have completed the required forms, but it doesn't mean the form is complete.
Alastair: another comment I had
was around the initiate.
... is it possible we could tackle it in Understanding.
... for commerce sites with a long list of products, and a buy
button next to each item.
... it seems like there could be quite a few examples where you
can initiate a process, some of which would be "under the
fold"
... makes me wonder how important those things are
... would we create a lot of noise. So I'm wondering if we
should remove the word initiate.
Katie: under 1.3.1 makes me feel
like this is delegating this to programmatically
associated.
... we do want things to work with AT, but this technique may
limit it to this.
... I'm not sure.
... there will be plenty of people not using cognitive AT.
Rachael: the original intent was
to make it easy to find important items. I am also hesitant to
just make it programmatically associated.
... it makes it a viable alternative when visible is not
possible, but seems to lose the intent.
... I am ok taking out the word initiate. This may make the
most sense for moving it forward.
... we may say at some point that this is something we need to
defer to Silver. I would rather make that decision as a group
if that is appropriate, instead of creating something that is
only a partial solution.
... that is a personal opinion.
<Ryladog> + I agree to that
Alastair: even if that is the
route we take, it is useful to have these discussions.
... Silver may have more flexibility around assigning
tasks.
... it is suddenly easier to say what is important, what is
not.
Rachael: it is
Alastair: what about the term
"high rank and call"
... do we need this?
... if the attribute is a good way to approach this, we may
need to scope this for technologies that do not have that
spec.
... like identify spacing or purpose.
... any other questions or concerns?
<Chuck> scribe: Chuck
detlev: From looking at this,
seems from discussions and examples, there are many cases quite
difficult to pin down.
... from testability and requirements. too many combinations
from where controls might go, not hopeful it can meet the
criteria of testability
... I agree with Rachael, better for Silver.
Alastair: Doesn't necessarily have to be easy. But I appreciate what you mean.
DM: Is the sc assume that a spec is ready for 2.2 for personalization and level of importance for attributes?
Alastair: We think personalization is ahead of wcag, but can mark as at risk.
<Zakim> mbgower, you wanted to say I'd like to see examples where design has failed to visually distinguish important control
mg: Rachael, the example is
useful. There aren't may failure examples. Is there commonality
in the examples that could help define this better? 4-square
example.
... Maybe important controls are persistant on screen. Maybe
compiling a list of problematic pages would give more
insight.
... If there are common design patterns that are
problematic.
Alastair: Good to know that things can be successfully implemented. It would help to have some failures as well.
dm: Is there a missing word in point #1? <reads>
mg: I flagged that too.
dm: What's the word?
Alastair: "it".
... or "the control"
... Does that make sense Rachael?
Rachael: I think so.
dm: Trying to figure this if it's a case of bad design or needing to supply good design to support coga.
Rachael: I think that a lot of it
is bad design. In my opinion is that bad and good design
overlap, but become disproportionate for coga.
... That's another problem we run into in these sc.
dm: Is there a way of wording to enforce good design? There's more than good design here. Lots of examples of surveys and inputs.
<alastairc> Rachael - Typeform would be an interesting case to look at.
dm: Submit button not visible on
screen, but apparent going through a vertical
implementation.
... ...that may be another way of isolating where good design
is still failing to make the step.
Rachael: I'll work on suplementing examples. Or do we need a call outside?
Alastair: Yes we can... It's kind
of scoping aspect that's tricky for which examples help.
... Ideally we would try and work on that up until Thursday and
make sure everyone can see updates Fri, Mon and Tue.
... If not we could shuffle this back and pull another one
forward, give you more time.
Rachael: Let's finish this out. I
had trouble finding long forms.
... If anybody is aware of long forms and send to me, that
would be helpful. Hopefully not behind firewalls or account
processes.
<Zakim> mbgower, you wanted to say my last point getting back to David's 1.3.1 comment is that it would be good to understand visual failures: 'Information, structure, and relationships
Alastair: I've an example to send you.
mg: Back to 1.3.1, I think if we
get personalization, if there's presentation that's making
things clear on importance, and we add on programatic
determinality
... That solves some of this. 1.3.1 can solve this. We can
focus on where 1.3.1 fails right now.
Alastair: Yes. I feel like
there's a whole new spec and see what sc can be applied.
... Good to know.
... This is our first review sprint. It went faster than
expected.
... We have 1 sc that has some reservations but it's not
blocking progress (tightly scoped). And this one which is more
"wider"
... newer in concept. We've had a good review, there's a few
things to try.
... May be better for silver (not a prediction though).
... Feels like maybe we can do 3 sc a week (that's our
velocity), if it's similar to this one.
... And we are out of agenda.
... Opening it up....
... Rachael we can discuss after the call, separately.
mg: Wondering if multi-step process owner is on the call.
Alastair: Who was
multi-step....
... John Kirkwood?
Rachael: John had undo.
Steve: The undo one we renamed to "confirm before submit". That's a multistep.
Alastair: Information in steps. David Fazio.
mg: I think I found some language that would address things we had last week.
<mbgower> In a multi-step process, all of the following are true: • A summary of entries in each step is presented before submission. • A user can traverse completed steps without affecting entered data
mg: I came up with
"traverse".
... <reads>
<alastairc> I think this one? https://docs.google.com/document/d/1e46eqQnVYqdSyqo29pyJoY1QynRH9v95YW8soTTbfsU/edit
mg: I think that addresses the idea that steps are completed, "traverse" gives the idea that one is moving through steps.
Steve Lee: Moving forward.
Alastair: I like that.
Steve Lee: Planning to work on that this week.
<Fazio> verbiage sounds nice
mg: exception already saying that if data affects further steps. This tighten this ups.
Steve Lee: Pros or bullet points.
mg: Either is fine with me.
... I couldn't find the sc doc, so I did it here.
Steve Lee: Will work on it this week.
mg: Send me link and I'll help.
<alastairc> https://www.w3.org/WAI/GL/wiki/Main_Page
Alastair: Any similar questions, use wiki page.
<alastairc> https://www.w3.org/WAI/GL/wiki/Upcoming_agendas
Alastair: It's a good starting
point, it's my bookmark for how I find things. If I can find
it, hopefully everyone else can.
... And I'm updating the agenda's page for future
meetings.
... I'll put in 'tbc' if not scheduled.
... After today I'll put in each of the review sprints with
survey as far into the future as I can go.
... It was difficult until today, now easier to keep up to
date.
... Open session now. Any q about sc they are working on or
others are working on. Or what is coming up.
... I have next, icon descriptions, dm was happy with that.
dm: I'm fine with going on with icon descriptions. I have some simple suggestions around mobile. Only concerns at TPAC.
<alastairc> Icon desc:
<alastairc> https://docs.google.com/document/d/1HzSsCGelWfz_Z-M7NyUzJOvl1A1kAStyl8epYdpZhoA/edit
dm: Other thing is the whole affordances conversation on visual indicators. From TPAC and comments it appears that this will be difficult to mandate borders.
<alastairc> Visual indicators: https://docs.google.com/document/d/1WhZAbswvPHs7A3stfqM_ATsaBHPeGbHtARcmaKMck1U/edit?usp=sharing
dm: Visual indicators on. I have a counter proposal we've been discussing online. If anybody from coga is on, we can discuss and see what the thoughts are.
Alastair: We have a few on from
coga.
... Do you want to make the proposal?
dm: Will drop into irc.
<david-macdonald> https://tinyurl.com/y657clzw
dm: a few things to discuss, this
sc came from a number of different conversations. Coga
discussed, low vision was concerned...
... buttons, links, interactive controls. We have been going
back and forth on language. Seems like it's going to be
difficult to get sc in 2.x
... when they seem kind of difficult, have to take a step back.
I thought that I could create a plugin that you hit one button
where all affordances go in.
... it would be very simple. On styles, just on buttons.
... links or borders would be other button. You'd have full
control over it.
<jon_avila> How would I access this on my mobile phone or tablet?
dm: just two simple buttons via
plugin.
... What we have been missing for coga is killer apps.
... tts is a killer app. game changer. existed before we
started wcag. If we did things to build to it, it would make a
difference.
<alastairc> jon_avila - that's always tricky, just exploring alternative ways forward.
dm: Maybe we would get more
traction if we modeled it after 1.4.12 which says "don't get in
the way of buttons that enhances styles".
... Kept it as simple as possible, take it from that
perspective... <reads from proposal>
... Modeled after 1.4.12. Buttons, input borders, upper limits.
That's the thought of stepping back and taking new
direction.
... From wcag 2.x model, this will get much better
traction.
Rachael: Like last conversation,
I have mixed feelings about not addressing visual side, but I
like the approach to get it through the framework.
... This is a way to get it through. Sad we don't have user
agents. We are missing the aps that take advantage.
dm: I agree. If we were to rely on styles, conversation on TPAC would be totally valid. Idea of downloading that gives a button to make stuff show up is a reasonable ask.
Alastair: User agents aspect of
it... we know about things like NVDA. I hope there are some
user agent side technologies. I'm aware of one...
... It's in research.
... I'm wondering if there are others. Just want to check that
we aren't re-inventing the wheel.
... Other aspect of operationalizing the requirement. Even
within a constrained space of focus styles, there's a huge
amount of variability.
... Getting down to bottom of example page, Cards with a 1
pixel outline, didn't occur to me before hand. Asking for
visual indicators across all kinds of things.
... Not knowing which is harmful and which isn't in advance. We
would need a lot of examples and research to make sure we
cover...
... ourselves and make a good case that it's a beneficial thing
to do and not unnecessarily restrictive. Not saying it isn't
impossible. But lots of work to go through scenarios.
<jon_avila> you can move on.
<jon_avila> sorry.
<jon_avila> please put me back on the queue
df: Are we talking about sc allowing for developers to use a plugin to meet the requirement?
Alastair: For visual indicators, we are talking about taking a step back and taking a personalization approach to allow for a plugin to work.
<jon_avila> I have several comments on the topic that I would like to share on this.
df: What plugins would be
applicable to coga?
... Another thing about the community is that with multiple
disabilities, we identify with one and not all. With AT we
utilize one type AT for one disability, and don't know to look
for all.
dm: If we go to 2nd page where it
says "rationale", I did POC. I'll stick my neck out and say I
can create a pluggin with one button that does this type of
css
... May have slider to offer some control, maybe pick a
color.
... Just the way that Steve Falkner came forward, we were
having difficult conversations. Made an app that checks
contrast.
... I don't think it's a great amount of effort. May be able to
provide a button that does this, in chrome store for
example.
<Ryladog> Bravo David!
dm: Someone with a cognative
issue would find it not too difficult.
... May have a setting button to change thickness or color. I
think in wcag 2.0 we thought about the standard as a
partnership between community that met with developers half
way.
... we assumed that they would know their AT and have AT
available. We provided a standard developers could build to.
This is same concept.
Steve: Lots of points there. <reads from sc>. I'm not getting what you are trying to say.
dm: I'm proposing we step back from first section, this is a proposal that's a new approach. I'm seeing very good substantial objections to current direction.
Steve: A good objection.. flat design, they don't have borders. Some have shadows.
dm: I wouldn't say "material
design". We can make a strong stand to say "may be fashionable,
but not good for accessibility".
... We may be hurting cognative by forcing... We take the same
position as text spacing. "Don't get in the way".
Steve: Another point, there are a
large number of AT. Not many aimed at coga specifically.
... One of those is a javascript bookmark that injects code.
They provide a number of options for user. Effectively
AT.
... A good point raised here. there's a trade-off, we stop
saying to content authors "you must", but define
symantics
... With coga stuff we've been saying we'll tell content
authors what to do. Good points. Didn't realize spacing was
already like this.
... For screen readers there's a lot of stuff not in sc.
... Saying "yes". Screen readers have been around for long
time. We don't have much for that. There's emmersive
reader.
... Others before that.
... That's one tiny area of the coga picture. Personalization
is an interesting topic. Once size fits one helps to not annoy
others.
Andy: A couple of questions
regarding deadlines for 2.2. I've been involved in silver, but
did want to work on these sc's.
... What are the deadlines and milestones for 2.2?
Alastair: For new things, it was about 4 weeks ago.
<alastairc> https://docs.google.com/spreadsheets/d/11IKqjRFvkRd2dAfUiyc5whhB3yIYXvSiirWct7KQIB0/edit#gid=0
Alastair: We have a list of 18ish
that ... these are current ones. Focus indicator ones are what
I would appreciate you looking at.
... You may be interested in others. For newer ones, that will
be longer terms. If we did a 2.3, we'd be starting that in a
year.
... Most are hoping that everything goes into silver after
2.2.
Andy: My concern is the one I've
been working on but haven't submitted yet, font weight. So many
web sites that use fonts with 1 pixel stroke width.
... Even black and white is an issue. Fonts are just too thin
to render that makes things readable. It's taking me longer to
get that together. Sounds like I missed for 2.2.
<jon_avila> I agree with Andi, I am seeing the same thing. The user agent is not rendering the font in a way that is dark.
Alastair: It's hard to predict
future. In 2.1 we struggled to get things in before the
deadline. Difficult process.
... IN 2.2 we don't accept everything. If we got towards the
deadline and decide we have everything we want, maybe we can
add.
Andy: Makes sense.
... Prominent changes in silver. I wanted to create some
bridges from wcag 2.2 to silver.
... Burried with silver activities. time got away from me.
Alastair: Don't throw it away please.
Andy: Don't worry! Part of silver.
ja: For dm, I realize there's a
give and take with user agents and authors. It's not as simple
as you stated.
... Authors could have a widget to enhance it, but google
sheets, focus was hard to see. I tried to address it, extremely
difficult and complicated. Not as easy as it seems.
... Can't just overwrite, it's at the document level. Selector
is at higher level, in my experience.
... Other concern is that if we do it here, why have a focus
indicator requirement if user can override? Why have a language
if at can determine?
... Where is the stopping point? We have to go beyond "it's
available".
... We should do a lot of things that don't require special
user agents, and available to everyone.
<Fazio> well said
<Zakim> alastairc, you wanted to ask about current user agent 'stuff', and say that this could be proof of concept that could be integrated with other UAs.
Steve: Inclusive design is key.
Alastair: Asking about current
user agent stuff. My experience is that coga and usability
testing they rarely use a particular technology.
... People do use chrome pluggins we advertise.
<Fazio> I use text to speech in apple pages
<Fazio> all the time
<Fazio> helps with cognitive fatigue
Alastair: What dm is working on could be a poc for showing if it's feasible. Hopefully if there's an all-around solution, it could be built into or copied.
<Fazio> Microsoft Word's version requires too many tasks to execute so I don't use it in word
Alastair: To John's point, we do
and try to work out the line of what we can ask of authors vs
user agents. More or less objection based process of getting
consensus.
... WCAG is accepted because if it gets through the process
it's reasonable to ask of authors. I'm happy to push
forward.
... My concern with visual indicators is complexity of working
out "if button needs border or not" how do we know how to
apply?
<Jennie> Options like Read And Write provide options in multiple environments. Some in our environment use Microsoft Immersive Reader for spacing/font changes.
Alastair: I'm sure that there's
good research. We also need research that talks to "in this
scenario this is what would apply".
... There are a lot of scenarios.
katie: I agree with a lot of what John said. The other reason I'm on queue, if there's a plan...
Alastair: Not for ag but for
silver, we were asking for a separate face to face in EU or US,
but got luke warm response.
... Getting funding for another trip is tricky.
dm: For every sc, there's going
to be situations where it doesn't help. But if you can
determine it helps a lot, and it's reasonable, then
... There's a good case to move forward. Working on 80-90 sc
for years, it's not likely that THIS sc will get through. Based
on my experience.
... I've put up a little stylus thing. One button, person would
select, all buttons would get outlines with a click.
... We could decide if we use underlines, changing colors,
thicker, that's the idea. 1-3 buttons.
... Just google pluggin. such as axe pluggin chrome.
... That's my thought. If we want to get something through in
next version.
Alastair: good discussion to
have.
... next week we'll continue with these 2 and add another
one.
<laura> bye
trackbot, end meeting
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/different scenarios/different themes/ Succeeded: s/indocators/indicators/ Default Present: Rachael, alastairc, Raf, Detlev, Fazio, Justine, Laura, Jennie, Brooks, Chuck, MarcJohlic, stevelee, Katie_Haritos-Shea, mbgower, david-macdonald Present: Rachael alastairc Raf Detlev Fazio Justine Laura Jennie Brooks Chuck MarcJohlic stevelee Katie_Haritos-Shea mbgower david-macdonald Regrets: Jake BruceB JohnKirkwood Nicaise Found Scribe: Jennie Inferring ScribeNick: Jennie Found Scribe: Chuck Inferring ScribeNick: Chuck Scribes: Jennie, Chuck ScribeNicks: Jennie, Chuck WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 08 Oct 2019 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]