RE: Regarding AccName and case sensitivity of roles and attribute values

Thanks, that’s what I was looking for.  I knew about the spec requirement, but have been asked to fix a bug where it wasn’t being forgiving enough in my own algorithm, and I wasn’t certain it should be.

It looks like I do have to fix a few bugs where HTML attributes need to be fixed where case is not so strict however. Such as type=”image” versus type=”IMAGE”.

Thanks for the help. 😊

Have a good weekend,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Steve Faulkner <faulkner.steve@gmail.com>
Sent: Friday, August 28, 2020 1:51 AM
To: Schnabel, Stefan <stefan.schnabel@sap.com>
Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com>; ARIA <public-aria@w3.org>
Subject: Re: Regarding AccName and case sensitivity of roles and attribute values

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

The W3C HTML validator

Example: https://validator.w3.org/nu/?showoutline=yes&doc=https%3A%2F%2Fcdpn.io%2Fstevef%2Fdebug%2FOJNmGOO


On Friday, 28 August 2020, Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>> wrote:
Steve,

Are you aware of any validators checking this?

Regards
Stefan

From: Steve Faulkner <faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>>
Sent: Freitag, 28. August 2020 09:38
To: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>
Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>; ARIA <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Re: Regarding AccName and case sensitivity of roles and attribute values

There are normative authoring requirements around this:

Authors MUST use lowercase ASCII letters<https://html.spec.whatwg.org/multipage/infrastructure.html#lowercase-ascii-letters> for all role token values and any state or property attributes (aria-*) whose values are defined as tokens<https://www.w3.org/TR/wai-aria-1.1/#propcharacteristic_value>.

https://w3c.github.io/html-aria/#case-sensitivity <https://w3c.github.io/html-aria/#case-sensitivity>

--

Regards

SteveF
Accessibility is political[✊]
Working for the web<https://twitter.com/stevefaulkner/status/940835584410574850>,
anywhere and everywhere [🖖🏽]


On Fri, 28 Aug 2020 at 07:31, Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>> wrote:
From my humble knowledge of the past group decisions, it IS strict and SHOULD be accepted by User Agents if correct.
User agents may apply internal heuristics to work around and therefore uppercase has no effect in practice.

But I think even some validators out there check already attribute case (Must look for examples here).

Regards
Stefan

From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: Donnerstag, 27. August 2020 18:32
To: ARIA <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Regarding AccName and case sensitivity of roles and attribute values

Hi,
Does anyone know how strict the case requirement is for ARIA roles and supporting attributes?

Since AccName changes depending on specific roles when present, I need to know if certain usages are automatically ignored or if they should be supported, such as if role=”tablist” is correct, but role=”TabList” is not. According to the ARIA spec, the second is not valid.

Please let me know your thoughts.

Thanks,
Bryan






Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>



--
--

Regards

SteveF
Accessibility is political[✊]
Working for the web<https://twitter.com/stevefaulkner/status/940835584410574850>,
anywhere and everywhere [🖖🏽]

Received on Saturday, 29 August 2020 00:11:09 UTC