Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update input-purposes for syntax highlighting #3380

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update input-purposes for syntax highlighting #3380

wants to merge 1 commit into from

Conversation

fstrr
Copy link
Contributor

@fstrr fstrr commented Sep 8, 2023 •
edited by pr-preview bot

In section 7 of WCAG 2.1/2.2, there is a list of "Input Purposes for User Interface Components".

This change simply updates the code from using <strong> tags to <code> tags, including the language attribute so they are styled as HTML.

The related PR 2614 includes this change, but also added a normative change. This PR is just to add syntax highlighting support.

This would apply to WCAG 2.1 and 2.2.

Preview | Diff

@fstrr
Update input-purposes for syntax highlighting
a79c0e4 
[PR 2614](#2614) includes this change, but also adds a normative change. This PR is just to add syntax highlighting support.
@fstrr
Copy link
Contributor Author

fstrr commented Sep 8, 2023

@alastc per today's backlog meeting, here's Input Purposes without the one-time-password line

@fstrr fstrr requested a review from alastc September 8, 2023 16:46
@fstrr fstrr self-assigned this Oct 20, 2023
@mbgower mbgower assigned alastc and unassigned fstrr Nov 24, 2023
@alastc
Copy link
Contributor

alastc commented Nov 24, 2023

@iadawn I think this is editorial (code change not content), but it's in the normative doc. I assume we don't need group approval (due to it being editorial), but won't appear until 2.2 is re-published?

@mbgower
Copy link
Contributor

mbgower commented Dec 11, 2023

@alastc I have moved this to the Done column, even though it is not merged -- and cannot be until republish, I believe. We don't really have another column to put it. I'm just going to leave you assigned to it for now.

@alastc alastc added the ErratumRaised Potential erratum for a Recommendation label Jan 15, 2024
@jenstrickland
Copy link

jenstrickland commented Feb 20, 2024 •
edited

Regarding the conversation in AGWG today around the dfn element the following is valid, semantic markup in the html validator.

<!doctype html>
<html lang="en">
<head>
<title>proof of concept</title>
</head>
<ul>
  <li><dfn>term</dfn> description</li>
  <li><dfn>term2</dfn> description2</li>
</ul>
</html>

References:

The nearest ancestor, the <li>, contains the definition for the term. It doesn't have to be a <p> or <dd>.

The reason to add the dfn is to semantically indicate this is a term that is being defined, which is what is happening here. For a dfn, unlike an abbr I don't really see that a title attribute pairs logically with it so perhaps it is useless to a screen reader user, however to those of us with cognitive considerations it does convey the semantics of the structure, as it would to parsing / programmatic technology.

@mraccess77
Copy link

While it could be valid - my understanding is that the parent p, section, or dd/dt would become the implied definition per the spec and information in that MDN article. I think that is why we would need to use a description list if we used dfn otherwise the definition would include too much.

@jenstrickland
Copy link

I've used the dfn for over 15 years and it is applicable in a list item. Dan Cederholm and Ethan Marcott's books use the pattern quite a lot.

It's only necessary for the definition to be included in the ancestor, which it is.

@patrickhlauke
Copy link
Member

patrickhlauke commented Feb 21, 2024 •
edited

is there any actual benefit (for users, right now, not just theoretically, and not just "when i then look at the underlying markup" but actually exposed in some user-friendly way with current tools) to using <dfn> ? or is this just semantics for semantics' sake?

@jenstrickland
Copy link

For some of us with cognitive considerations it helps. It's also useful programmatically for the non-humans parsing content. I also read that screen reader users can choose settings to leverage the dfn and abbr tags.

@patrickhlauke
Copy link
Member

patrickhlauke commented Feb 21, 2024 •
edited

It's also useful programmatically for the non-humans parsing content

that falls mostly under the "theoretical" part, unless there's actual examples out there of such tools.

I also read that screen reader users can choose settings to leverage the dfn and abbr tags

that's news to me, I have to admit. would be good to know if this is actually happening, rather than again just being theoretical. purely for the <abbr> case, it's not looking good https://www.powermapper.com/tests/screen-readers/labelling/acronym-abbr-title/ / https://adrianroselli.com/2024/01/using-abbr-element-with-title-attribute.html ... and I don't believe the situation with somehow doing something sensible (or at all) with <dfn> is any different at the moment

@mbgower
Copy link
Contributor

mbgower commented Feb 23, 2024 •
edited

@jenstrickland

I was unable to find much documentation about support for the dfn tag. I do note that it is used in the html5 spec on the section we are 'reproducing' here, which speaks in its favour.

Do you see the existing changes proposed in this PR -- replacing the strong element with the code element-- as producing a better or worse outcome than what exists right now, or making no difference? The reason I ask is that if you view code as preferable to strong, I believe the easiest path forward is to adopt the PR (not get bogged down on something that is an improvement), and make a new issue, wherein the relative merits of <def>, <dt> and any other definition pairs can be properly hashed out.
If you view the use of the code element as detrimental to the existing structure, then I think you should vote thumbs down on this PR, which may cause it to be sent back In Progress in the TF, where the approach can be debated.

@jenstrickland
Copy link

jenstrickland commented Feb 23, 2024 •
edited

The code element is definitely an improvement from the strong.

dfn would be an enhancement. I figured better to do it at the same time. Happy to submit a PR separately. I'm not recommending using a def or dt.

Thank you for your kind response!

@bruce-usab
Copy link
Contributor

Discussed on call, dfn should be a separate issuee

@alastc
Copy link
Contributor

alastc commented Feb 23, 2024 •
edited

Hi Jen,

Regarding the conversation in AGWG today around the dfn element the following is valid, semantic markup in the html validator.

I think something missing from the conversation is what the dfn is intended for, which is where you have multiple instances of a term on the page, and the dfn is for the defining version of that term. (Hat tip to @scottaohara for that point.)

That isn't very explicit in the specs, but if you look at the examples it become clearer.

That usage is not what we're doing in WCAG, as each is the only instance of the term on the page.

Given that each item is intended to be an attribute value in HTML code, the <code> element makes the most sense to me.

Using a definition list is potentially an alternative, but it would be styled like the other instances (e.g. 1.1.1), I don't see any practical benefit from changing the current PR.

@jenstrickland
Copy link

I'm not challenging the code element at all.

I'm saying that it can be wrapped in a dfn as it is the defined term within the li. The language within the li explains the code.

The dfn does not require the use of a dl.

This is a separate issue from changing strong to code. I'm wishing I hadn't asked the question during the call.

@bruce-usab
Copy link
Contributor

@jenstrickland please open a new issue for your recommendation to use dfn in this context (or elsewhere in Understanding, if you like).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@scottaohara scottaohara scottaohara approved these changes

@alastc alastc Awaiting requested review from alastc

Assignees

@alastc alastc

Labels
1.3.5 Identify Input Purpose Async-Approval Bug Fixes ErratumRaised Potential erratum for a Recommendation Normative WCAG 2.1 WCAG 2.2
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
8 participants
@fstrr @alastc @mbgower @jenstrickland @mraccess77 @patrickhlauke @bruce-usab @scottaohara