There are two answers to this, but let's start with the one that seems most applicable to the examples you've given:
Definition of Done
The Definition of Done is a checklist maintained by the team that can be applied to every user story. Often times, this includes things like unit test coverage, regression testing and code reviews. However, sometimes this is a good place to include architectural constraints. For example, you could have a checkbox in your Definition of Done that reads:
Any UI element renders properly in Firefox, Chrome, IE, as well as Apple and Android default mobile browsers.
Navigation elements have had hallway usability testing to ensure they are intuitive
Emergent Architectural Requirements
If you've broken down your user stories well, architectural requirements will emerge. For example, if I had a story like:
As a user, I would like to be able to view my points earned this month so that I can see my progress toward the next reward.
you could break that down into "As a desktop user" and "As a mobile user". This is the ideal approach because it gives you more choice and encourages more creative solutions. It's easier for the Product Owner to prioritize which features on which devices offer the most value. It also is more likely to result in solutions that are truly optimized for their device, not just copied. The downside is you have to be vigilant about making sure your stories are always broken down well and no one simply forgets and that if your technical practices aren't strong, you can box yourself into a lot of rework.
Don't forget that both options are available to you. Some might work better in your DoD while others will work better emerging out of user stories.