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

DRAFT: Subjective applicability #539

Closed
wants to merge 5 commits into from
Closed

DRAFT: Subjective applicability #539

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
43ce209
Subjective applicability draft.
tbostic32 Jul 25, 2023
9b840ac
Update act-rules-format/act-rules-format.bs
tbostic32 Aug 23, 2023
ddbce11
Adding glossary definition features.
tbostic32 Aug 23, 2023
c8b05a9
Update act-rules-format/act-rules-format.bs
tbostic32 Aug 23, 2023
d9cc98a
Merge branch 'w3c:main' into tbostic/subjective_applicability
tbostic32 Dec 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 12 additions & 3 deletions act-rules-format/act-rules-format.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -405,11 +405,20 @@ The applicability describes what parts of the [=test subject=] are tested.

### Applicability for Atomic Rules ### {#applicability-atomic}

The applicability section is a required part of an [=atomic rule=]. It <em class="rfc2119">must</em> contain a precise description of the parts of the [=test subject=] to which the rule applies. For example, specific nodes in the DOM [[DOM]] tree, or tags that are incorrectly closed in an HTML [[HTML]] document. These are known as the [=test targets=]. The applicability <em class="rfc2119">must</em> only use information made available through the listed [input aspects](#input-aspects) in the rule. No other information can be used in the applicability. Applicability <em class="rfc2119">must</em> be described objectively, unambiguously and in plain language.
The applicability section is a required part of an [=atomic rule=]. It <em class="rfc2119">must</em> contain a precise description of the parts of the [=test subject=] to which the rule applies. For example, specific nodes in the DOM [[DOM]] tree, or tags that are incorrectly closed in an HTML [[HTML]] document. These are known as the [=test targets=]. The applicability <em class="rfc2119">must</em> only use information made available through the listed [input aspects](#input-aspects) in the rule. Definitions used in the description can be put in the rule [glossary](#glossary), or they can be defined in the section where they are used. No other information can be used in the applicability.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an aside, I think we should remove the

tags that are incorrectly closed in an HTML document

wording, since this refers to 4.1.1 which is getting deprecated in 2.2.


An objective description is one that can be resolved without uncertainty, in a given technology. Examples of objective properties in HTML are tag names, their computed role, the distance between two elements, etc. Subjective properties on the other hand, are concepts like decorative, navigation mechanism and pre-recorded.
Applicability <em class="rfc2119">must</em> either be described objectively or use an **allowed subjective form**, and <em class="rfc2119">must</em> be written unambiguously and in plain language. An objective description is one that can be resolved without uncertainty, in a given technology. Examples of objective properties in HTML are tag names, their computed role, the distance between two elements, etc. When possible, objective descriptions <em class="rfc2119">must</em> be used since they reduce uncertainty.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last sentence here

When possible, objective descriptions must be used since they reduce uncertainty.

And the second sentence of the paragraph below

When possible, subjectivity must be avoided since it can easily be misunderstood.

say the same thing, but I couldn't figure out in which location I liked it better, so I kept both and wanted to hear opinions. Is it better to be affirmative (i.e., "Do use objectivity) or negative (i.e., "Do not use subjectivity")?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first sentence is clear enough

Copy link
Collaborator Author

@tbostic32 tbostic32 Jul 27, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In last sentence, must -> should and explain when/why

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep both.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think providing both is best.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In agreement with both.


Even concepts like headings and images can be misunderstood. These terms could refer to the tag name, the semantic role, or the element's purpose on the web page because they are ambiguous. The latter of which is almost impossible to define objectively. When used in applicability, potentially ambiguous concepts <em class="rfc2119">must</em> be defined objectively. Definitions can be put in the rule [glossary](#glossary), or they can be defined in the section where they are used.
Subjective properties on the other hand, are concepts like decorative, navigation mechanism and pre-recorded. When possible, subjectivity <em class="rfc2119">must</em> be avoided since it can easily be misunderstood. For example, concepts like headings and images could refer to the tag name, the semantic role, or the element’s purpose on the web page because they are ambiguous. The latter of which is almost impossible to define objectively. In some cases, where meeting the objectivity requirement is impossible, the use of a subjective description in the applicability is acceptable.

To deal with the inherent problems of subjectivity, any applicability including subjective descriptions must meet the following criteria: (1) use one of the allowed subjective forms, (2) place all subjectivity inside of a glossary definition, and (3) the applicability section must be clearly marked as subjective.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: We need to determine how we want to mark the applicability as either objective or subjective.

Possible easy solutions could be changing the heading per rule to be "Objective Applicability" or "Subjective Applicability", or having a small sentence/note that says "This applicability is objective/subjective". Open to opinions.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a slight preference to not modify the Applicability heading. Indicating subjective in the text would be fine.

Would it be acceptable to only require indicating subjective? Then, "unless indicated otherwise, the applicability is objective" could be used.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do like Kathy's call out, in that you are stating the baseline is objective, unless you are calling out the exception and then go in to what the exception is, (subjectiveness)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we even need to track subjectivity in the rule. That's an open question for me still. If we do, it feels more like metadata, like the rule ID or the publication data. It's not that important for most readers I expect

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Put in the metadata but have displayed on the published page for implementer/user situational awareness.

tbostic32 marked this conversation as resolved.
Show resolved Hide resolved

**Allowed Subjective Forms**:
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of thoughts here, is it clear that the things in brackets are the "fill in the blank" portion of the form? I should maybe add more verbiage to this.

Is "Objective target description" the best verbiage we can use to state what the subjectivity is applying to?

Is "role/common design pattern/subjective attribute" good wording for what kinds of subjectivity go with each form? I think not, this to me is the weakest part of this addition and the one that needs the most fleshing out and thought.

1. [Objective target description] is styled as a [role]
2. [Objective target description] functions like a [role/common design pattern]
3. [Objective target description] is/has/expresses [subjective attribute]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one feels too vague to me. One thing I think I'd like to do is for us to go over the subjective definitions we have today and see if we can categorise them somehow. Maybe see which ones we think would be okay for use in an applicability and which ones aren't.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be good to revisit it now with more context, but my initial stab at finding some of the subjectivity types we use are in act-rules/act-rules.github.io#2061 (comment). That is where these 3 forms originally came from, they seemed to deal with the examples I found as well as some I had seen people want to use.


The subjectivity allowed in each of these forms must be explicity included in glossary definitions to ensure common understanding of the scope of the subjectivity. For example, a rule with a subjective applicability “HTML element is styled as a heading” would require the creation of an agreed upon definition for what constitutes “styled as a heading”.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we like this? Or is this just additional overhead? What other ways could we form it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be stated to minimize subjectivity or is that obvious? Meaning [role] and [role/common design pattern] are objective. Use these whenever possible.

Examples with explanation under each would be helpful. Copying from act-rules/act-rules.github.io#2061 (comment):

[Thing] is styled/looks like a [role] - Example: Element is styled as a heading
[Thing] operates like a [role/widget] - Example: Element operates like a checkbox
[Thing] is/has/expresses [subjective attribute] - Examples: Text node is purely decorative, Text node expresses anything in human language, Element is non-text content

Another thought -
I've encountered [Thing] functions as a heading (but not styled as a heading). For ex:

Applicability. The applicability describes what parts of the [=test subject=] are tested.

With this, I wonder if [functions as] could be used instead of [styled] in other [styled] examples.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Kathy's note on functions as vs. styled, are we staying away as markup and coded as terms to use? If we are evaluating Web content, yes the element is going to styled , however the element could be a paragraph tag or it could be a heading level tag, so the first thing would be to confirm the facts of what elements are used ('p') or (heading level) then determine applicability / subjectivity .


<aside class=example>
<header>Example applicability of an atomic rule testing [WCAG 2.1 success criterion 1.4.2 Audio Control](https://www.w3.org/WAI/WCAG21/quickref/#audio-control):</header>
Expand Down