How do screenreaders handle ::before and ::after?

I am styling a document and I am using special characters to visually style buttons, for example:

<button type="button">&gt; Do Something</button>

Now I know that I can hide the greater than sign for screen reader using the aria-hidden attribute:

<button type="button"><span aria-hidden="true">&gt; </span>Do Something</button>

But because this is not really content, but rather styling, I was thinking about putting the greater than sign before the button using the ::before element like this:

<button type="button">Do Something</button>

<style>
  button::before {
    content: ">";
  }
</style>

This would make it much easier to add buttons to the document using JavaScript. It also is on rule that applies to all buttons, without having to set it on every button again.

Now, how do screen readers handle the content in these ::before and ::after elements?

In addition to that question, does it make a difference how the styles are loaded? E.g. inline, using a link or with a style tag?

(I've read about the CSS speak property, but it doesn't seem to be supported anywhere yet...)

Solution

Now, how do screen readers handle the content in these ::before and ::after elements?

It depends on the screen reader, browser and OS combination used. Sometimes it is rendered, sometimes it isn't.

As far as I remember, Jaws+IE and Jaws+firefox don't render it, nor NVDA+IE, but NVDA+firefox does for example.

In consequence, you'd rather don't use ::before and ::after. At least, don't use them to convey important information. Aria-hidden is much more widely and uniformly supported.

ADditionally, both are legitimally acceptable, if we look at it well:

Outside a few notable exceptions (display:none for example), screen readers shouldn't bother with CSS, since CSS give instructions for presentation only. IN this logic, since it's just presentation, it isn't important, so let's ignore ::before and ::after.
IN the opposite side, ::before and ::after are text contents to be added to the element. Technically we can create a DOM element for displaying that text (probably that some browsers do it that way). Since it's a DOM element now, there's no reason not to render it.

IN short, that's controvertial. In the same kind of contradiction, we have CSS counters, and quoting via CSS. Are these two only presentation ? probably not entirely. Is text in ::before and ::after only presentation ? IN your case yes, but you can as well add some text being not presentational at all.

In addition to that question, does it make a difference how the styles are loaded? E.g. inline, using a link or with a style tag?

It doesn't change anything as far as I have tested.

(I've read about the CSS speak property, but it doesn't seem to be supported anywhere yet...)

CSS speak won't probably ever supported. That's a 10+ years old project, more or less abandonned nowadays, for quite good reasons.

Things like voice, genre, accentuation, pitch, how to make pauses according to punctuation, sound cues, etc. are private preferences to be configured by the screen reader user. Website designers musn't interfer with that in any way. There exists really no "standard voice" that would be acceptable for most users. Websites aren't audio books. Audio books are cool, but they don't serve the same purposes.