Maybe.  I haven't used Pygame in a while.  I prefer Pygllet, but that is very much less friendly for new programmers even if it is architecturally better in the long run, and my big thing these days is C++ digital signal processing anyway.
Work out how to do the following things in order.  If you have already done some of these, that's fine; if you have trouble, ask because one of the Python people here can probably help:
Make accessible output 2 say something.
Make a Pygame window appear.
Say the pressed key.  Don't worry about modifiers, but if I press a then say a.  This will break some for punctuation, also don't worry about that.  All the screen reader output methods in everything do it without a bunch of extra steps that are not worth it here.
Get a counter incrementing and decrementing when you press the arrow keys.  Don't let it go below 0 or past a maximum value that you define.  Announce the changes to this counter.
Now you're at the point of doing a menu.  I suggest a menu class.  You'll have a list of strings (the options), a run function which starts running a little private Pygame loop and getting keys and incrementing and decrementing the counters.  When enter is pressed, you return the string for the option or the index of the option or whatever.  Alternatively (depending how much you know) you make the list of options a list of tuples where the first item is a string and the second item is a function to call and then call that when the user presses enter.  Whatever you can manage or need is fine.  It's about 30 to 40 lines and it's reusable.
And that's it.  If you need, I can type up a class with some functions that you call, but I honestly think working out how to do this yourself is ultimately more helpful.  This is the most basic method, but there are more advanced options.  Be aware only that this isn't necessarily sufficient forever (but it is for a good while).  This will work for a simple side-scroller where every interaction pauses things; this will not work for an online game where everything has to keep going because you can't pause everyone or where you need to implement something like a Swamp radar.  It's simple but it leads to a lot of code duplication and controls will not be mappable.  Get this far and if you care we can talk about more advanced options.

Hello,
There's a game_utils Python module for simplified making of audio game stuff including menus. It hasn't been updated since 2013 though. It's made by Q-Continuum also known as Accessible Apps. It's using sound_lib, a simplified BASS library wrapper, also made by Q-Continuum, as well as accessible_output for speech output.
http://hg.q-continuum.net/game_utils/archive/tip.zip
Although I'm programming in Python by default, I decided to try making my games with BGT. Of course, both making games in Python and BGT has advantages and disadvantages.
Python syntax is far easier to read, but you have to care about indentation.
In BGT, game executables are smaller in size, and work faster. In Python, you will get a larger game distribution, and will work slower, especially if we talk about loading a game.
In Python, you can make cross-platform games with not too many modifications. In BGT, you can make only Windows games.
In BGT, you can easily pack and encrypt your sounds, which makes hackers much harder to get access to them. In Python, I think the only way to protect your sound files is by putting them inside the password-protected zip file, which can still be easier to hack, in my opinion.
Correct me if I'm wrong though.

Thanks everyone. So I wrote out a class Menu(), but I can't get it working the way it should be. I am still a little new to using classes, but I understand how they work.

When I run my program it just runs game() and rules(), and says [start game, none]

Can someone help?

here is my code:

this is what I am passing in

                mainMenu = [["Start Game", game()], ["Start Rules", rules()], ["Exit", "Exit"]]
                main = Menu()
                main.run(mainMenu, "Main Menu")

class Menu():
        def run(self, items, title):
            #mainMenu = [["Start Game", game()], ["Rules", rules()], ["Exit", "exit"]]
            itemNumber = 0
            itemsLength = len(items)
            currentItem = items[itemNumber]
            closeMenu = False
            spk(title)
            spk(currentItem)
            while closeMenu == False:
                for event in pygame.event.get():
                    key = pygame.key.get_pressed()
                    if key[pygame.K_t]:
                        spk(title)
                    if key[pygame.K_RETURN] or key[pygame.K_ENTER]:
                        return currentItem[1]
                    if key[pygame.K_DOWN]:
                        itemNumber += 1   
                        spk(currentItem)
                    if key[pygame.K_UP]:
                        itemNumber -= 1
                        spk(currentItem)
                    if key[pygame.K_x]:
                        spk("closing menu")
                    closeMenu = True

All right, sorry, a couple things. First I did realize that my indentations were off, I was consistent so my program ran fine and I wasn't paying close attention. Second thanks for the tip for the functions I didn't know that. I Changed that in my list and I am still getting weird output. It is different though. Also, I did not right a condition for the case of the item number being larger or smaller yet. I did know that it was an issue, sorry for not making that clear in the previous post, I just wanted to get this working first.
Can you explain more about why i should use tuples?
Also, I actually try and follow Pep8 when I am righting nontesting python, but here I am just trying to get this working for my own knowledge base. What standards am I not following other than doc strings and comments? I have not read the standards for classes yet sinse I just learned them recently. I am probably going to do that right now.

I actually found a couple other errors too. I didn't include the index number when I was refering to the currentItem to access the sublist.
That actually helpd quite a bit, however now I am not able to change to the next item in the list.
My new output is something like
main menu start game. like it should be, but when I press down errow it does nothing, or it is just lagging a lot I noticed I was having a problem with lag earlier.

I was able to use a find and replace on my tabs to convert them to spaces to make it more readable to NVDA and Jaws. I forget that when pasting code into forms you have to account for tabs converting.

Also I forgot to mention a couple other things to clarify. The game() and rules() functions just output accessible_output, and the function spk I am using I created to simplify accessible_output.

def spk(text):
    speech.Speaker().output(text)

calling and passing in:
mainMenu = [["Start Game", game], ["Start Rules", rules], ["Exit", "Exit"]]
main = Menu()
main.run(mainMenu, "Main Menu")

class Menu():
    def run(self, items, title):
        itemNumber = 0
        itemsLength = len(items)
        currentItem = items[itemNumber]
        closeMenu = False
        spk(title)
        spk(currentItem[0])
        while closeMenu == False:
            for event in pygame.event.get():
                key = pygame.key.get_pressed()
                if key[pygame.K_t]:
                    spk(title)
                if key[pygame.K_RETURN]:
                    return currentItem[1]
                if key[pygame.K_DOWN]:
                    itemNumber += 1   
                    spk(currentItem[0])
                if key[pygame.K_UP]:
                    itemNumber -= 1
                    spk(currentItem[0])
                if key[pygame.K_x]:
                    spk("closing menu")
                    closeMenu = True

Hmmm, what you seem to be doing is playing the first item in the mainMenu list, but not actually updating it. When you set itemNumber += 1 your not actually using it to select the new current item, I think it should be more like this:

class Menu():
    def run(self, items, title):
        itemNumber = 0
        itemsLength = len(items)
        closeMenu = False
        spk(title)
        spk(items[itemNumber][0])
        while closeMenu == False:
            for event in pygame.event.get():
                key = pygame.key.get_pressed()
                if key[pygame.K_t]:
                    spk(title)
                if key[pygame.K_RETURN]:
                    return items[itemNumber][1]
                if key[pygame.K_DOWN]:
                    itemNumber += 1   
                    spk(items[itemNumber][0])
                if key[pygame.K_UP]:
                    itemNumber -= 1
                    spk(items[itemNumber][0])
                if key[pygame.K_x]:
                    spk("closing menu")
                    closeMenu = True

It might depend on at whivh point your pressing up, you don't have any code to keep itemNumber in bounds of the list. Try this and see if it helps:

                if key[pygame.K_DOWN]:
                    itemNumber += 1   
                    if itemNumber > len(items)-1:
                        itemNumber = 0
                    spk(items[itemNumber][0])
                if key[pygame.K_UP]:
                    itemNumber -= 1
                    if itemNumber < 0:
                        itemNumber = len(items)-1
                    spk(items[itemNumber][0])

I'm not all that familiar with the pygame event loop, so i'm not entirely sure what may be causing it. I've dug through a few examples so you could try writing it like this:

class Menu():
    def run(self, items, title):
        itemNumber = 0
        itemsLength = len(items)
        closeMenu = False
        spk(title)
        spk(items[itemNumber][0])
        while closeMenu == False:
            for event in pygame.event.get():
                if event.type == pygame.KEYDOWN:
                    if event.key == pygame.K_t:
                        spk(title)
                    if event.key == pygame.K_RETURN:
                        return items[itemNumber][1]
                    if event.key == pygame.K_DOWN:
                        itemNumber += 1   
                        if itemNumber > len(items)-1:
                            itemNumber = 0
                        spk(items[itemNumber][0])
                    if event.key == pygame.K_UP:
                        itemNumber -= 1
                        if itemNumber < 0:
                            itemNumber = len(items)-1
                        spk(items[itemNumber][0])
                    if event.key == pygame.K_x:
                        spk("closing menu")
                        closeMenu = True

If that doesn't work then someone more familiar with pygame may have to chime in, either that or i'd have to take some time to install and familiarize myself with it.

Hi,

This isbecause JAWS uses what we call a keyboard hook, which means it intercepts all key presses before letting them through to the currently focused application. I'm not sure if Pygame has a keyhook to fix this or not, but that's what you'll need for JAWS.

I see what you are talking about. It seems to be a Jaws issue. NVDA reads the menu perfectly.

To clarify the possible issue, as you posted while I did:
Jaws is an invasive kudzu vine of horror.  Instead of just grabbing what it needs in a sane manner, it does a bunch of process injection and whatnot, and handles a lot of keys it shouldn't and in cases where it shouldn't.  If this is the issue here, you need a thing that makes Jaws stop hooking; if this is the issue here, then I will drop everything and go make a Python package for it, because this hits me as well as you and shouldn't be a difficult fix.  At least, it's not difficult if I know what's going on, and I think I do.
But I still pose the question: Swamp doesn't do this. SoundRTS doesn't do this.  If this is the issue, does that mean that Jaws users are just not playing those games?  Are they simply not complaining?

Hi,
That was a JAWS problem for ages. You really have to turn it off to play most of games, and implement either SAPI or recorded voice for game prompts.

Yeah, I'd be interested in a c version.

Though I wonder how many people who play audiogames who use jaws actually needs this, because most people would just have another less buggy/broken screen reader installed.