doc(securing-your-webhooks): show test values

[coolaj86]

Why:

It's always good to have test values to know that a subtle difference in implementation isn't causing buggy behavior.

What's being changed (if available, include any code snippets, screenshots, or gifs):

Adding test values.

Check off the following:

• I have reviewed my changes in staging, available via the View deployment link in this PR's timeline.

  • For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

• For content changes, I have completed the self-review checklist.

[welcome]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[github-actions]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
webhooks-and-events/webhooks/securing-your-webhooks.md	fpt ghec ghes@ 3.10 3.9 3.8 3.7 3.6 ghae	fpt ghec ghes@ 3.10 3.9 3.8 3.7 3.6 ghae

---

fpt: Free, Pro, Team
ghec: GitHub Enterprise Cloud
ghes: GitHub Enterprise Server
ghae: GitHub AE

[cmwilson21]

@coolaj86 Thanks so much for submitting a PR! I'll get this triaged for review ⚡

[skedwards88]

Thanks for adding this! I'm going to modify the format a bit, then we'll get this merged for you.

[github-actions]

Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our help wanted issues ⚡

[coolaj86]

I'm also going to switch from a code block to a list, which might be slightly more accessible for screen readers.

We know that:

• this documentation is for programmers
• very few programmers use screen readers
• it's a net negative to make something marginally worse for the many to make it marginally better for the few
• "might be slightly more accessible" is equivalent to "might be slightly less accessible" (i.e. it's a null argument)

Lists are almost always the worst representation for data - right behind paragraphs.

A table might be better in both cases.

A code block is acceptable.

I don't really think it needs more words. There's already a lot of duplicate information and - much like code, more sentences means more things that have to be maintained. Less is more.

That said, SEO or whatever, tomato potato. Maybe there's an advantage to more words. That might be subjective. I'd prefer just an easy to copy/paste block. Meh.

However, converting easily digestible code blocks into difficult-to-read lists... definitely no bueno.

[janiceilene]

@coolaj86 You can read more about GitHub's commitment to accessibility in https://github.blog/2022-12-02-github-accessibility-and-the-disability-divide/