Ottawa, Ontario
Account created on 19 July 2005, almost 19 years ago
#

Recent comments

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Looks like it almost runs on SimplyTest.me, but would be good if it did.

Are there any pre-installation things that need to be done?

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Can we get someone to re-roll this patch?

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks @rkoller this is great. I'd like to see this patch include Ralf's suggestion to collapse the first drop button as soon as another drop button is expanded. We don't want to introduce an accessibility issue for keyboard only users, by fixing an issue for screen reader users.

I would say that from Ralf's demo that the patch would currently violate SC 2.4.11: Focus Not Obscured (Minimum) (Level AA).

Let's open up a follow-up item about the drop button label, as suggested by Ralf.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Just tagging it here.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding sustainability-team

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Just changing the name for better SEO

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks for raising this at today's Drupal A11y Office Hour Simo!

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I think that the JavaScript could likely be done with something like https://stackoverflow.com/questions/1655769/fastest-md5-implementation-i... but there are probably better ways to do this.

It is also interesting to think about the CO2 costs of loading extra JS and weight that against the occasions where someone uploads a file. I don't know how to balance that score out, but it is something to think about.

Much easier to think about adding a library to do the md5 hash on the backend I assume. It would only be executed when needed.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Sorry, I don't know that this should be tagged with sustainability given that this is a bug in an edge case. Should be fixed, but I'm changing my mind.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

WebP look ready to roll though:
https://caniuse.com/?search=webp

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I don't know why we're trying to add this to D7 at this point. Bumping it up to D10. Hopefully we don't have to wait till 11.

AVIF & WebP are already ready to roll:
https://caniuse.com/?search=avif
https://caniuse.com/?search=webp

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Doesn't seem to be a lot of support for JPEG XL https://caniuse.com/?search=JPEG%20XL

AVIF & WebP look ready to roll though:
https://caniuse.com/?search=avif
https://caniuse.com/?search=webp

Also, we can build on the work of another CMS that's already moved this way:
https://wagtail.org/blog/wagtail-greener-and-leaner/

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

How often are we running these tests? Seems like a good investment of time to cut the execution time in half, even if it's a matter of allowing us to know earlier that the patch works.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Great to see this.

This is how Wagtail is currently doing this:
https://wagtail.org/sustainability/
https://wagtail.org/blog/wagtail-greener-and-leaner/

Also an idea for relative CO2 impacts (all estimates of course):
https://sustainablescreen.org/unlocking-sustainable-speed-optimising-ima...

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

mgifford β†’ created an issue.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Nice. Any sense of how many bytes or even kb's might be saved by doing this? Given the number of Drupal installs in the wild, this seems like it could reduce a lot of CO2 distributed across our community.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I would like to have some nightwatch-axe Core tests set up to test the new navigation. I think that the dynamic functionality that we're going to want to be able to deliver should come with some dynamic automated tests.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I'm just looking at the source here.

// Because CKEditor5 re-renders aria-label every time on focus/blur,
// overwrite the label to appropriate field label value.

This sounds like an upstream bug. Shouldn't CKEditor just do this:

// Update aria-label with the value from default textarea label.

Not that we can't too, but surely, if there is a label in the text area, CKEditor should respect that, right? Or am I missing something?

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Interesting.. I hadn't heard of AccessibilityHelp before this:
https://ckeditor.com/docs/ckeditor5/latest/api/module_ui_editorui_access...

Documentation for authors is definitely important:
https://accessibilitycluster.com/main-results/documentation

But this seems to be about help for authors who need to learn the keystrokes that are needed to use CKEditor.

Keep in mind that there are inherent problems with Keyboard Shortcuts https://webaim.org/techniques/keyboard/accesskey

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Worth comparing with https://dequeuniversity.com/library/aria/progress-bar-bounded

Many uses of progress bars are essentially static, but Drupal we often use them as dynamic elements which should be updated with aria-live.

Deque uses:

<div id="progressbar-bounded" class="deque-progressbar deque-progressbar-bounded">
  <progress role="progressbar"
  aria-valuemin="0"
  aria-valuemax="100"
  aria-label="A bounded progress bar from 0 to 100">
  </progress>
  <p>
    <button class="deque-button" id="start-progressbar">
      Start
    </button>
  </p>
</div>

They leverage the ARIA progressbar role. I"m not certain that this is needed, but wanted to note it here.

MDN just states:

If the progressbar role is applied to an HTML
element, the accessible name can come from the associated . Otherwise use aria-labelledby if a visible label is present or aria-label if a visible label is not present.

What is in the latest patch I think is:

  <div id="${id}" class="progress" aria-live="polite">
        <label>
          <div class="progress__label">&nbsp;</div>
          <progress class="progress__element" value="0" max="100"></progress>
        </label>
        <div class="progress__percentage"></div>
        <div class="progress__description">&nbsp;</div>
  </div>

I'm not sure how much the JavaScript would affect things here either. I haven't compared the two.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

How is what we implemented different than what you can see in their demo https://ckeditor.com/ckeditor-5/demo/feature-rich/

The contrast I see for the focus of the boarder is #3879EB / #FFF which is 4.1.2. That's good enough for SC 1.4.11 Non-Text Contrast (Level AA) if the visual presentation only needs a contrast ratio of 3:1 against adjacent color(s).

I didn't see a corresponding problem in their issue queue https://github.com/ckeditor/ckeditor5/issues

but the bigger issue is that i couldn't replicate this in their demo.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks @rkoller. Thanks for documenting this all. It would be great to help make it easier to identify what elements are active. We can make this easier for everyone to identify.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks smustgrave - I appreciate you verifying that. I wasn't starting with D11 but obviously should have been here.

That makes sense @camille.davis@civicactions.com

I tested with code without that.

In which case I don't have a problem removing the redundant text.. Who wants redundant text!

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I like this idea, but I'm missing something.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attribut...

I couldn't find aria-current="page" in the page.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attribut...

Here's a snapshot of what I see with SimplyTest.me & D10:

<li class="tabs__tab js-tab is-active js-active-tab" data-original-order="1">
  <a href="/user/1/shortcuts" class="tabs__link js-tabs-link is-active" data-drupal-link-system-path="user/1/shortcuts">Shortcuts</a>
      <button class="reset-appearance tabs__trigger" aria-label="Tabs display toggle" data-drupal-nav-tabs-trigger="">
      <svg fill="none" height="16" viewBox="0 0 16 16" width="16" xmlns="http://www.w3.org/2000/svg"><path clip-rule="evenodd" d="m15 9h-14c-.56016 0-1-.43984-1-1s.43984-1 1-1h14c.5602 0 1 .43984 1 1s-.4398 1-1 1zm0-5h-14c-.56016 0-1-.43984-1-1s.43984-1 1-1h14c.5602 0 1 .43984 1 1s-.4398 1-1 1zm-14 8h14c.5602 0 1 .4398 1 1s-.4398 1-1 1h-14c-.56016 0-1-.4398-1-1s.43984-1 1-1z" fill="#003ECC" fill-rule="evenodd"></path></svg>    </button>
  </li>

I've uploaded some screenshots with/without the patch.

I'd love to know what I am missing.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

We should definitely fix this. After listening to this page with a screen reader it clearly needs work. I think it was working better when we first introduced this in Drupal 7, but time erodes all things.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

There's been some discussion in Slack to move the password strength indicator before the input form so that a user is told how they should comply before fill in the form. I thought that the password strength indicator was semantically linked to the password field by aria-describedby but can't seem to find that now.

I suspect with these changes we should put on "Needs Accessibility Review" and "Needs Usability Review" but I wonder if we can't commit this and create two smaller follow-up issues.

This one is already approaching its 10th anniversary.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I took a look with this issue with VoiceOver, and with keyboard-only reviews. This looks good. Like the new pattern with the show/hide text.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I don't know how to do this. There are two times.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks for posting this @rkoller. It is clear you've put a lot of work into this and giving it a lot of careful consideration. I wanted to emphasize that not all accessibility errors are covered by WCAG SC. Cognitive is going to be covered much better in WCAG 3.0 but it is likely years away before this becomes a W3C Recommendation. That doesn't mean we can wait to address these issues.

I do think that it would be great to do more usability studies with our authors and admin. Would be interesting to do A/B testing with different ways of organizing and separating the content.

This also may be a space to explore the use of prefers-contrast to allow more individual choice.

It would be interesting to see if there are ways that design folks could address some of these concerns in ways that me (as a non-designer) can't necessarily anticipate.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Just adding a reference for this:
https://web.dev/articles/control-focus-with-tabindex#remove_an_element_f...

It is easy enough to test for everyone with a keyboard.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I needed to say which months were what

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Identifying two different times for the monthly meetings.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

mgifford β†’ created an issue.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

My only concern with this change to:

background: #004eff;

background: var(--color-blue-500);

is that I'd like to know what the ratios are to the foreground color.

#004eff has lots of room with a foreground of #fff
https://www.whocanuse.com/?bg=004eff&fg=ffffff&fs=16&fw=

I need to know what the values would be for var(--color-blue-500).

Knowing this I think we can remove the Needs accessibility review tag.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks for adding that @shaal.

I do think that there must be a reasonable solution to work for from that mix of links. Doesn't need to be perfect, but should be able to do up/down as well as left/right so that we can change order and hierarchy.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Just taking myself off of this list as I keep having conflicts or not being able to make it. I may re-join in the future.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

@swirt, I like your YAML style direction, but it is different than what is proposed here:

https://humanstxt.org/Standard.html

Maybe something like this:

/* Drupal Core Maintainers */
    See core/MAINTAINERS.txt

/* Site - see https://humanstxt.org - for format suggestions */

/* Please add site specific contributions below */

/* TEAM */

Your title: Your name.
Site: email, link to a contact form, etc.
Social Media: whatever you use   
Location: City, Country.

							
/* THANKS */
					
Name: name or url

                            
/* SITE */

Last update: YYYY/MM/DD           
Standards: HTML5, CSS3,..
Components: Modernizr, jQuery, etc.
πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

This makes sense to me. It's a simple change, but one that I think can avoid some confusion for users expecting a link.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Think Windows High Contrast Mode (WHCM) is being used as "high contrast" more consistently.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding reference to Windows High Contrast Mode.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Good call @andy-blum.

As far as things we could possibly support.
- Support for AAA colors
- Support for a low contrast mode (we really haven't touched on this at all, but could be useful for some users).
- Dark mode
- Defined custom colors for: foreground-color, background-color, text-decoration-color, text-emphasis-color, border-color, outline-color, column-rule-color

I don't have a lot of guidance on how to do this, which is which I've included a bunch of research links as well as opening this as a meta issue.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Crossing out inverted-colors because of lack of support https://caniuse.com/?search=inverted-colors

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Let's continue to build on this for now. It's a short issue.

I changed the title so that it reflects that there is now a description.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

This is terrific. Thanks @dmundra

So how often should we review this list of URLs?

Probably that should be a new issue. Should we close this one?

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding a section about Nightwatch axe. 

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding clarification about accessibility section. 

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding a link to https://nightwatchjs.org/ and some basic spelling/grammer things. 

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding new article, The Road to Accessible Drag and Drop (Part 1) https://www.tpgi.com/the-road-to-accessible-drag-and-drop-part-1/

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I love the idea of making the caption visible as an option. It could definitely improve the experience by providing better context for everyone viewing it.

The <caption> element is within the <table> so it is by default associated with data the tables so I'm not tagging this as 1.3.1 SC.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

@rkoller & I were talking. This advent calendar article came up You don't need JavaScript for that. Most browsers support the dialog element now.

Not that this would be a trivial shift, but it does seem like this might be a good time to consider it.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

There are always dangers in overwriting the default browser behavior. It is usually more work than it is worth. Still, Eric's article is focusing on the page scroll bar and I can't find references to scroll bars within the page.

Worth looking into though.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

User-first or Standard-first... :)

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Adding a section on screen magnification. 

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Looking at some recent examples, including Scott's above, I'm not sure that we need any aria for the detail/summary. There was an outstanding bug for NVDA, but I think that's been resolved now.

Some follow-up links:

Wouldn't it be nice if we could just get it down to very basic HTML - <summary class="claro-details__summary">

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I was just chatting with @rkoller about how nice it would be to actually know how people are using the admin breadcrumbs. Would be so useful to know if folks are going to our help.

If there is a way to enable this so that we can learn more about how authors and admins use their sites it would be so valuable. So often we just have to make assertions based on what we think would be useful to these users. Sadly, extrapolations from developers is rarely as good as watching those trying to use their Drupal site.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

It would be great to get a list of the URLs that are presently being covered by axe. There are some issues sneaking into Core that should have been caught by automated testing.

As with any good CI/CD process, it is important to monitor that list of URLs on a regular basis to ensure that we are using the best sampling that we can.

Phase 1 & 2 in the description identified some key URLs. It is unclear (without digging into the code) which URLs are being tested.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

This makes sense to me. Why wouldn't we include this as a part of the Core Accessibility Gate?

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I just ran that PNG through https://tinypng.com/ and was able to reduce its size from 15kb to 6kb..

Can we make sure that when we are creating images which will be distributed widely across different sites, that we take a moment to compress them?

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks @catch

I do like the idea of not running this on the weekend, but then again, not everyone shares the same idea for a weekend. I don't know enough abut the GitLab interaction to know if there's a way to check for commits.

Maybe there would be folks from GitLab who might have ideas on their side about how to reduce their server usage.

Does seem to be the kind of thing that should be part of a good aproach to ESG. https://about.gitlab.com/environmental-social-governance/

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I definitely prefer the show/hide feature to be outside the input field. That example with the Light/Dark mode that you pointed to in the Youtube video would work well. Would allow us to have the button as a button too. Probably we'd want to swap the text or image to let folks know that their password is now visible (or invisible).

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Even adding an HR would help.

Here's a useful guide to best practices as of 2023 - https://adrianroselli.com/2023/10/splitting-within-selects.html

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Would love to see this get in.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks for catching that @rkoller. Really appreciate you looking over this in the UX channel and providing the feedback here.

I'd missed that name field was a required field. Are there any instances where this wouldn't be the case?

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Wanted to flag this the accessibility concerns about properly labelling it:

In most cases you should provide an accessible label when using <progress>. While you can use the standard ARIA labelling attributes aria-labelledby or aria-label as you would for any element with role="progressbar", when using <progress> you can alternatively use the <label> element.

I would say that using <label> is better.

<label>
  Uploading Document: <progress value="70" max="100">70 %</progress>
</label>

More good examples here - https://scottaohara.github.io/a11y_styled_form_controls/src/progress-bar/

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

This looks great. Look forward to seeing this bug fixed.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

This looks good to me. We're just re-implementing existing/tested patterns. Happy to see this in Core.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I can confirm in the /admin/structure/taxonomy

That the focus state is not announced to the screen reader user.

Here's a simple recording with VoiceOver.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

I haven't tested with a screen reader yet @camilledavis, but definitely agree that the behavior in losing focus is a problem. It is a relatively small area. Folks shouldn't have to keep it over that small spot to continue reading the menu.

I attached a movie of the experience.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks for starting this thread @rkoller and documenting it so well.

Would be great to be able to move to using the dialog element.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

We needed guidance on animations.

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Thanks @GreenSkunk I do think that this could be quite useful to show to authors. There are these PHP based tools like https://github.com/DaveChild/Text-Statistics which the Content Readability module uses but also worth noting that this could be delivered through JS too.

https://github.com/yichiang/plain-language-checker
https://github.com/duereg/too-wordy
https://github.com/retextjs/retext-readability
https://github.com/clearnote01/readability
https://github.com/btford/passive-voice/tree/master

One challenge for Drupal with this is that most of these are really focused on English specifically or at least European languages.

@quietone I moved this back to Drupal core as it really should be something we look at for CKEditor 5. Really don't see any interest in developing anything new on CKEditor 4.

Production build 0.69.0 2024