profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/patrickhlauke/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Patrick H. Lauke patrickhlauke UK https://www.splintered.co.uk WCAG trash panda, web evangelist, ronin, sour kraut, rex kramer - danger seeker. vague, but exciting.

jquery-archive/PEP 1656

Pointer Events Polyfill: a unified event system for the web platform

patrickhlauke/getting-touchy-presentation 41

Everything you (n)ever wanted to know about touch and pointer events

patrickhlauke/aria 32

Basic demos and introductory presentation about WAI-ARIA

patrickhlauke/browser 1

The browser extension vault (Chrome, Firefox, Opera, Edge, Safari, & more).

patrickhlauke/JSTouchController 1

A simple demo of multitouch dual analogue controls in JavaScript

patrickhlauke/accessibility-insights-web 0

Accessibility Insights for Web

patrickhlauke/accname 0

Accessible Name and Description Computation

patrickhlauke/aviewer 0

Inspection tool for Windows accessibility API information (MSAA, IAccessible2, UI Automation, ARIA, HTML DOM)

PR opened w3c/wcag

Reviewers
2.5.3 - control with label but no accname (understanding note + new failure technique)

Closes #2045

+86 -2

0 comment

3 changed files

pr created time in 6 hours

create barnchw3c/wcag

branch : patrickhlauke-issue2045

created branch time in 6 hours

push eventinclusivedesign24/inclusivedesign24.org

Patrick H. Lauke

commit sha ac6b1b9b0f649c3adae5756a7b33d2116e74a9fc

Tweak pre-show and afterparty titles

view details

push time in 12 hours

pull request commentw3c/wcag

Update contrast-minimum.html

"Normal" vision is a specific definition, and a clinical definition

doesn't the same also apply to "Color Blind"?

bruce-usab

comment created time in a day

issue commentw3c/wcag

Align Target Size (min) with Target Size (enh)

and i just noticed that my issue https://github.com/w3c/wcag/issues/1832 is basically a dupe of this (but again, as with my comment on the proposed draft response - same as this one), the issue here like mine has nothing to do with the response given. the issue that both @WilcoFiers and I have is consistency of the wording of 2.5.8 to make it match 2.5.5's wording more closely.

WilcoFiers

comment created time in a day

issue commentw3c/wcag

WCAG 2.2 2.5.8: add the (possibly redundant) mention of "pointer inputs" to match 2.5.5

@jenstrickland my issue had nothing to do with the "44x44" measure or anything.

My issue is: for consistency, can the normative wording of the new AA SC be more in line with the 2.1 AAA SC?

i.e. since the 2.1 AAA SC starts with

2.5.5 Target Size (Enhanced) (AAA) The size of the target for pointer inputs is at least 44 by 44 CSS pixels...

it would make sense to use the same/similar wording for the new 2.5.8 AA SC and change

2.5.8 Target Size (Minimum) (AA) Targets have an area of at least 24 by 24 CSS pixels...

to

2.5.8 Target Size (Minimum) (AA) The size of the target for pointer inputs is at least 24 by 24 CSS pixels...

patrickhlauke

comment created time in a day

Pull request review commentw3c/wcag

Re-doing the border aspect.

 <h4>Unusual shapes and gradients</h4>                     <figcaption> The focused button with the non-contrasting areas removed, showing that it is a thick indicator that meets the requirements.</figcaption>                 </figure> -                <p>If an inline link is broken over two or more lines, the indicator can be split between them. In this case the link element is still treated as a single control.</p>+                <p>If an inline link is broken over two lines, some methods of outline are treated differently by browsers. Using CSS, an outline will either wrap each part of the link separately, or wrap the whole link as one perimeter. Each part of the link will pass or fail as though they were separate links. If a border is used the indicator can be split between them. When using a border the thickness may need to be increased to compensate.</p>

suggest adding commas for better readability

If a border is used, the indicator can be split between them. When using a border, the thickness may need to be increased to compensate.

alastc

comment created time in a day

PullRequestReviewEvent

push eventinclusivedesign24/inclusivedesign24.org

Patrick H. Lauke

commit sha 35209db09a5da79ed355cd80f4fab17ca4635d3f

Update YouTube link to the shorter (working) version

view details

push time in 2 days

issue commentw3c/wcag

Focus indicators for large editing areas

+1

alastc

comment created time in 2 days

push eventinclusivedesign24/inclusivedesign24.org

Patrick H. Lauke

commit sha d4e9f44cd65a5d23e2ad648f8871123cfd6a5082

Remove timer from homepage

view details

push time in 3 days

push eventinclusivedesign24/inclusivedesign24.org

Patrick H. Lauke

commit sha 0e6378db4d0e8a4b05a52827982e06ecc40f7cf4

Remove timer from homepage

view details

push time in 3 days

issue commentw3c/wcag

Form / Input Errors Vs. states Vs. 1.4.11 Non-text Contrast Vs. 2.4.11 Focus Appearance (Minimum)

sure, but i'd also say we need to be realistic - WCAG sets a baseline, and it makes not reaching the baseline effectively illegal (depending on context, legislation that just adopts WCAG by reference, etc). we'd need to be very sure that we have solid normative parameters, and that we're not overreaching in shackling designers/developers to necessarily only allow one particular style/presentation, i'd say...

jake-abma

comment created time in 3 days

pull request commentw3c/wcag

Removing complexity

non-rectangular?

awkawk

comment created time in 3 days

issue commentw3c/wcag

Does SC 2.5.3 fail when there is a visual text label but the control has no accessible name?

yeah, that's my thinking too. add a clear wording to the understanding (as per @mraccess77 though nitpick "this criterion" (!) singular) and a failure technique. i can have a go at doing a PR once id24 is over tonight/tomorrow

mraccess77

comment created time in 3 days

issue commentw3c/wcag

Form / Input Errors Vs. states Vs. 1.4.11 Non-text Contrast Vs. 2.4.11 Focus Appearance (Minimum)

this isn't attempting to expand the definition, it's just giving more examples. an being invalid (e.g. aria-invalid) is a state of some UICs. sure, not all of them can be invalid. but then again, not all of them can be checked/unchecked/pressed/etc. the nuance is already there now that those states may not apply to every possible UIC

jake-abma

comment created time in 3 days

issue commentw3c/wcag

Do skeleton loaders fall under “inactive” exemption of 1.4.11 Non-Text Contrast?

@patrickhlauke would you say that a loading spinner to indicate a loading state would not need to meet contrast then? these skeleton states are essentially the same thing. If there's no other non-failing 'loading' text or indicator, i don't think this is really a best practice alone.

perhaps thin-slicing, but the spinner/loader is a "thing" in its own right, which appears and then disappears, while the placeholder skeleton is replaced/turns into actual content and interactive components (links, buttons). but yes, it's a wobbly distinction, admittedly.

mra11yx

comment created time in 4 days

issue commentw3c/wcag

Do skeleton loaders fall under “inactive” exemption of 1.4.11 Non-Text Contrast?

to @scottaohara's point about the normative definition of user interface component, it gets blurry if the skeleton placeholder structure also contains dummy controls for instance that are, at that point, inactive...so don't think it's a super-useful distinction. i'm still a bit on the fence, but my gut feeling is exempt the skeleton for being a large inactive "component" of sorts, but as best practice still make sure that there's something visible there.

mra11yx

comment created time in 4 days

issue commentw3c/wcag

Do skeleton loaders fall under “inactive” exemption of 1.4.11 Non-Text Contrast?

even simple inactive components like a <button disabled>...</button> do convey information that "there's some functionality that you may have at some point, but not just now", so even for those the exemption is a bit...rubbish to be honest. but applying the same logic as for those, i'd say yes those skeletal structures can be seen as exempt, but as best practice i'd have some contrasty-enough indication that there's something there

mra11yx

comment created time in 4 days

issue commentw3c/wcag

Form / Input Errors Vs. states Vs. 1.4.11 Non-text Contrast Vs. 2.4.11 Focus Appearance (Minimum)

for 1., i'd say yes being "invalid" (in the case of erroneous form controls) is a state.

the definition of state only gives examples, so the current list (focus, hover, select, press, check, visited/unvisited, and expand/collapse) is not meant to be exhaustive. It could of course have more added (best to do at this stage, as doing a normative change later after publication would be a painful process). Suggest adding further examples of disabled, invalid. I'd also say the existing list could do with some normalisation to make sure they're all adjectives - focused, hovered, selected, pressed, checked.

for 2., i'd say also consider 1.4.1 Use of Color for the "is the change from other state visible enough" (e.g. in case of an underline or border that changes from gray to red or something). don't think personally that there should be a need for any particular SC that defines how "visible"/"noticeable" errors need to be, beyond the other SCs that cover visual aspects. otherwise we get into needing to normatively define how much of a visual change is normatively required to count as a "visible" error message/notification, which sounds like a painful and subjective exercise.

jake-abma

comment created time in 4 days

issue commentw3c/wcag

Text spacing: does it require compatibility with one or all methods?

@alastc can this issue be closed since https://github.com/w3c/wcag/pull/1687 which tried to address this was merged? or are there still aspects left open to discuss?

JAWS-test

comment created time in 4 days

issue commentw3c/wcag

Text spacing: does it require compatibility with one or all methods?

as the SC is scoped to In content implemented using markup languages that support the following text style properties..., purely native apps are out of scope. technically native/hybrid apps contain webviews with actual markup language content, there's no practical way for a user to actually change text spacing metrics (however they do it ... a bookmarklet, extension, user stylesheet, etc). theoretically you could test the actual web content inside the webviews in isolation in a browser, and I suppose technically the SC does apply to the webview content itself - so a pedant may insist on testing those. not sure what the rest of AGWG think on this...

JAWS-test

comment created time in 4 days

issue openedw3c/w3c-website

Broken-looking 'g' and 't' characters in font

Not sure if it's due to some slightly broken hinting or similar, but the lowercase 'g' looks rather odd on the design system site at least on Windows (but correct on macOS).

Chrome/Windows

Screenshot of 'Third party plugins' showing the odd-looking 'g'

Screenshot of 'design' showing the odd-looking 'g'

Firefox/Windows

Screenshot of 'design' showing the odd-looking 'g'

Note that once you zoom in, the look of the 'g' sorts itself out, which is why I'm thinking it's some bad hinting.

Screenshot of enlarged 'design', with the 'g' looking correct

EDIT: just noticed similar issue with the lowercase 't' as well

Screenshot showing the lowercase 't' looking odd

created time in 4 days

push eventinclusivedesign24/inclusivedesign24.org

Patrick H. Lauke

commit sha e0e4187e903c9ea9ca0904681d8b2ecf197ef7b1

Swap out TetraLogical logo for coloured one

view details

push time in 4 days

push eventinclusivedesign24/inclusivedesign24.org

Patrick H. Lauke

commit sha d9f876ac022aceb48f51b793eb62763b4168d1c0

Swap adobe logo for the coloured one

view details

Patrick H. Lauke

commit sha 1bcc145445b0ed1a935818ee710377b828152b4f

Add CFID silver supporter

view details

push time in 4 days

push eventinclusivedesign24/inclusivedesign24.org

Patrick H. Lauke

commit sha e4ebef84c571b7d6fea83f5d7d407d0e64caa550

Add Kenji live captions url

view details

push time in 5 days

push eventinclusivedesign24/inclusivedesign24.org

Patrick H. Lauke

commit sha 354400561d157c810b2afa1d32e4d1707397990e

Add Kenji live captions url

view details

push time in 5 days

push eventinclusivedesign24/inclusivedesign24.org

Patrick H. Lauke

commit sha a42e1498785584a89e3498702c28a81874f7059a

Add Kenji live captions url

view details

push time in 5 days

issue commentw3c/wcag

Does SC 2.5.3 fail when there is a visual text label but the control has no accessible name?

we can agree on the requirement for an accessible name for 2.5.3 , but during the development of this SC we never discussed the => 1. an accessible name is required, 2. the label must be part of it.

it's perhaps splitting hairs, but: we're not saying (at least i'm not) that the above rationale says "the SC requires that there is an accessible name". the requirement is still as discussed. it's just that if there is NO accessible name, and there is text/image of text that acts as label, then it's an automatic fail of the "is the label text part of the accessible name". a subtle difference. this isn't trying to sneak in a new requirement clause, it's just the logical conclusion of the existing normative text.

mraccess77

comment created time in 5 days