Usage of "content author" vs. "author"

[rahimabdi]

Describe the change

I'm observing the following 6 spec instances of the term "content author":

Section	Text
Section 5.2.1 Abstract Roles	Content authors MUST NOT use abstract roles because they are not implemented in the API binding.
5.2.2 Required States and Properties	Content authors MUST provide a non-empty value for required states and properties. Content authors MUST NOT use the value undefined for required states and properties, unless undefined is an explicitly-supported value of that state or property.
5.2.3 Supported States and Properties	Content authors MAY provide values for supported states and properties, but need not in cases where default values are sufficient.
alertdialog	Content authors SHOULD make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog.
6.1 Clarification of States vs. Properties	Because the distinction between states and properties is of little consequence to most web content authors, this specification refers to both "states" and "properties" simply as "attributes" whenever possible.

Is "content author" different than a "web author" or the predominant spec term "author"?

Link to the version of the specification or documentation you were looking at

Link to documentation: https://w3c.github.io/aria/

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?

Yes.

[scottaohara]

imo, all of these instances should just be changed to 'author', but effectively they are meant to be treated the same.

for instance, wcag mostly just uses the term 'author' - but will extend that to 'content author' in a few instances, particularly when trying to distinguish from other types of authoring. for instance:

The work follows a research-focused, user-centered design methodology to produce the most effective and flexible outcome, including the roles of content authoring, user agent support, and authoring tool support.

[giacomo-petri]

While updating "Content authors" with "Authors" I've also checked all the other instances of "Author/Authors".
Along the way, I've come across different scenarios where different terms are utilized, such as "Application author/s", "Web application author/s". I'm listing those below:

Section	Text	Status
3.3 Assistive Technology Notifications Communicated to Web Applications	Likewise, web application authors SHOULD update the web application accordingly when notified of a change request from the user agent or assistive technology.	Ok as is, but simplified for clarity
link role	If this is a native link in the host language (such as an HTML anchor with an href value), activating the link causes the user agent to navigate to that resource. If this is a simulated link, the web application author is responsible for managing navigation.	Can be replaced with "author"
6.8 Definitions of States and Properties (all aria-* attributes)	Below is an alphabetical list of WAI-ARIA states and properties to be used by rich internet application authors. A detailed definition of each WAI-ARIA state and property follows this compact list.	Ok as is, but might be worth to simplify with author? Also, it seems like there is a very specific category of authors, which are ARIA-authors. Also here, maybe might be worth to replace it with "authors". I did the change but happy to revert if there is no consensus
aria-invalid state	If the value is computed to be invalid or out-of-range, the application author SHOULD set this attribute to true. user agents SHOULD inform the user of the error. Application authors SHOULD provide suggestions for corrections if they are known.	Can be replaced with "author"
aria-readonly property	Readonly elements are relevant to the user, and application authors SHOULD NOT restrict navigation to the element or its focusable descendants.	Can be replaced with "author"
1.4 Co-Evolution of WAI-ARIA and Host Languages	New types of objects are continually being developed, and one goal of WAI-ARIA is to provide a way to make such objects accessible, because web authoring practices often advance faster than host language standards. In this way, WAI-ARIA and host languages both evolve together but at different rates.	I'm a bit uncertain about this one. ARIA stands for Accessible Rich Internet Applications, so I believe "authoring practices often advance faster..." would be sufficient
6.1 Clarification of States versus Properties	Because the distinction between states and properties is of little consequence to most web content authors, this specification refers to both "states" and "properties" simply as "attributes" whenever possible.	Can be replaced with "author"
8.6.1 ID Reference Error Processing	It is the web author's responsibility to ensure that IDs are unique. If more than one element has the same ID, the user agent SHOULD use the first element found with the given ID. The behavior will be the same as getElementById.	Can be replaced with "author"

The majority of them, while possibly correct in some contexts, can be replaced with simply "author/s." Thinking it would be beneficial to maintain consistency, I simplified them to "Author/s."

The only sentence where it might be appropriate to retain it as is, is:

User agents MUST provide a method to notify the web application when a change occurs to states or properties in the system accessibility API. Likewise, web application authors SHOULD update the web application accordingly when notified of a change request from the user agent or assistive technology.

which is in the context of the specific section related to web applications:

3.3 Assistive Technology Notifications Communicated to Web Applications

I'm uncertain if we wish to retain it as it is, or if, since it is the only instance of "different author," we should replace it with simply "author." I've updated it to "Author" but happy to revert if there is no consensus.

[scottaohara]

fwiw, i read through each of your changes before reading this issue - and it all looked good to me.

[rahimabdi]

Thank you @giacomo-petri!