Remove use of parentheses on its own sentence as per WAI Style Guide.

[daniel-montalvo]

See https://wai-website-theme.netlify.app/style-guide/structure-presentation/#parentheses-optional

Need for Call for Review:
This can be merged with 1 approval << choose reason: editorial changes to website/test code, adding new contributor, other (explain). >>
This will not require a Call for Review, editorial changes (including to the applicability, expectation or examples section).

---

Pull Request Etiquette

When creating PR:

• Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• Add label to indicate if it's a Rule, Definition or Chore.
• Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• Optionally request feedback from anyone in particular by assigning them as "Reviewers".
• If your PR is for a new rule with an Accessibility Support note, or for updating the Accessibility Support note of an existing section, make sure to open a corresponding Accessibility Support issue.

When merging a PR:

• Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

[netlify]

❌ Deploy Preview for act-rules failed.

Name	Link
🔨 Latest commit	e773ddb
🔍 Latest deploy log	https://app.netlify.com/projects/act-rules/deploys/6a5e2d58d89c8a0008b3ca5e

[dan-tripp-siteimprove]

Suggested change

	This link has [visible inner text][] that, according to the [label in name algorithm][], is contained within the [accessible name][]. This example shows why the [label in name algorithm][] uses the [visible inner text][] and not the [visible text content][]: the `<h6>` tags insert whitespace into the result in the former but not the latter.
	Similar to previous example. This link has [visible inner text][] that, according to the [label in name algorithm][], is contained within the [accessible name][]. This example shows why the [label in name algorithm][] uses the [visible inner text][] and not the [visible text content][]: the `<h6>` tags insert whitespace into the result in the former but not the latter.

I have no strong opinion on parenthesis. I think there's value in the words "Similar to previous example" somehow. My rationale is that, because this example's paragraph copied about 95% of its words from the previous example's paragraph, if we don't warn the reader about that somehow, then we will force the reader to read this example more carefully, and that's unnecessary mental effort.

[daniel-montalvo]

Thanks for giving the context @dan-tripp-siteimprove

It may be probably best to just focus these two descriptions on what makes the two examples different, not on what makes them similar.

If we keep "Similar to previous example.", I would instead use a comma to avoid having an incomplete starting sentence.

Similar to previous example, this link has [...]

[dan-tripp-siteimprove]

That sounds good to me.