Is it a valid or acceptable practice to develop a separate page to meet accessibility requirements?

I recently visited some websites that seems to be using either deprecated technology (e.g. Flash) or contain a lot of complex front end javascript code to create the interaction of the user interface.

Some of these websites provide a link or button that takes you to a accessibility mode page which strips all the unnecessary features and provide just the content that is optimised for screen readers and provide other accessible features (e.g. keyboard navigation).

With accessibility being such a big focus today, and inclusive design slowly being incorporated into many of the standard design systems, is it still seen as an acceptable practice to provide a separate page to meet accessibility guidelines (i.e. WCAG 2.0)? Are there other reasons why this might be a better strategy/option in the current design and development culture?

Is storing a JWT secret as docker env variable acceptable?

I understand how JWTs work and that with my secret anyone can issue new tokens. I control the server that my node website runs on and am considering different options for hosting the key.

  1. In code – Not acceptable because my code is in a github repo
  2. ENV variable – seperate secrets for dev and production while not leaking to github
  3. Store in database – Seems more like #2 with more work, being that an on-machine attacker can find access to the db anyways

2 looks like the best method for a simple website (no super sensitive user info like credit cards or SSNs). Is this a good solution?

Would Epic Heroism be an acceptable rule variant for a small, first-time group?

I’m DMing a group with 4 players. For all of us, this is our first D&D experience. We’ll be playing Lost Mines of Phandelver.

I’m concerned about the survivability, especially given how green the players are. At first level, they’ll have 10 or 12 hit points, facing groups of goblins that can hit for 1d6+2. I’m adjusting the number of monsters in each encounter, but still worry.

Healing seems to be very rare. At first level, the spellcasters will have the ability to cast two spells in an entire dungeon.

Epic Heroism (DM Guide p267) seems like it could help, but might tip the balance too far the other way into easy mode:

This variant uses a short rest of 5 minutes and a long rest of 1 hour. This change makes combat more routine, since characters can easily recover from every battle. You might want to make combat encounters more difficult to compensate.

Spellcasters using this system can afford to burn through spell slots quickly, especially at higher levels. Consider allowing spellcasters to restore expended spell slots equal to only half their maximum spell slots (rounded down) at the end of a long rest, and to limit spell slots restored to 5th level or lower. Only a full 8-hour rest will allow a spellcaster to restore all spell slots and to regain spell slots of 6th level or higher.

Am I missing some element that would make the party more likely to survive the first dungeon, or would this rule variant be a good way to introduce the mechanics of the game?

Are dismissible banners acceptable UI for purchase confirmations?

Here’s some context:

A user on a Free account is editing a draft in our text editor. To be able to publish the draft (they get auto-saved), they need to purchase a plan.

When they click on the “Upgrade” button, they are taken to the Checkout flow. After Checkout completion, what is the best way to confirm their purchase?

  1. A screen that says “Purchase was successful” with a CTA that will take them back to the editor?

  2. Or take them back to the text editor, but append a banner notification up top that says their purchase was successful?

I would think Option 1 would be the best way to go about it. IMO, a purchase is a big deal/big decision, hence a warrants its own single page instead of just a banner?

Dropdown of dates, is it acceptable to display in non-chronological order

We have a time series graph. The user can use a drop down to select their years and these years are displayed on the chart. Currently, the drop down is just a list of years for the past 30 years.

My superior is discussing ordering the drop down, not by chronological order of years, but based on a value, such as busiest year. My concern with this is that there will not be an expected order to the drop down. Years will be all over the place, 2017 might be at the bottom whilst 2019 might be at the top.

I simply can’t allow this to happen, as I think it’s very confusing to anyone trying to find a year. So I suggested we find a different way. They’re suggesting we use a checkbox to modify the drop down. Eg, default to chronological and change the drop down to busiest to least-busy year if checkbox is selected. I still have issues with this as I’m yet to see a website use boolean modifiers against a drop down, I think we’ll struggle to make it clear the link between the drop box and the checkbox.

Any suggestions?

Enum design: when an “open” set would be acceptable as enum’s values?

I was looking into the Enum design recommended by Microsoft (see here), and I found a statement that made me stop to think for a while:

X DO NOT use an enum for open sets (such as the operating system version, names of your friends, etc.).

It says that OS versions are considered as open set, therefore it should not be enumerated. Moving forward with my doubt: I’m developing a proxy to an API, and I’m thinking in allow the proxy’s consumers choose the API version. The approach that I got in mind it’s just define an enum that lists all the API versions, thus consumers are allowed to pass which API version they want to use.

However, due to API versions is something that would be considered as open (eventually there will be more versions), I’m doubting in include the version choosing feature. So, does this guideline not fit in my scenario?

Should tests perform a single assertion, or are multiple related assertions acceptable

Assume a client is making a request to an API endpoint that returns a JSON response where the structure and data change depending on whether the request was successful or not. Possible responses may look as follows:

Scenario with a success response

{   "status": XXX,   "data": [{     ...   }] } 

Scenario with a failure response

{   "status": XXX,   "errors": [{     ...   }] } 

Example of test scenarios for the above would be:

  • Assert the expected status code
  • Assert the expected JSON structure
  • Assert the expected JSON data

When performing tests where you have more than one assertion you can perform, is it recommended to provide a single test for each assertion, or group the assertions into a single test?

Retrofit response retornando null com codigo 406 Not Acceptable

Fala pessoal, to usando Retrofit2 com Kotlin e estou tentando realizar uma requisição POST onde será retornado um Json.

A requisição é feita e a parte do servidor funciona (cadastra o usuario), porem quando vou tratar o response, ele sempre retorna null (com código 406 Not Acceptable)

Requisição feita no Postman: Requisição feita no Postman RetrofitConfig.kt

class RetrofitConfig(baseUrl: String) { private val gson = GsonBuilder().create() private val httpClient = OkHttpClient.Builder() private val retrofitBuilder = Retrofit.Builder().baseUrl(baseUrl).addConverterFactory(GsonConverterFactory.create(gson)) private var retrofit =  fun loginService(): LoginService {     return createService( }  fun registerService(): RegisterService {     return createService( }  fun <S> createService(serviceClass: Class<S>): S {     retrofitBuilder.client(     retrofit =     return retrofit.create(serviceClass) } 


interface RegisterService {     @POST("registrar/")     fun registrar(@Body usuario: Usuario): Call<AuthResponse> } 

Realizando a Requisição

val call = RetrofitConfig(baseUrl).registerService().registrar(usuario)      call.enqueue(object : Callback<AuthResponse> {         override fun onFailure(call: Call<AuthResponse>?, t: Throwable?) {             Toast.makeText(this@AuthFragmentRouterActivity, "Sem conexão com a internet.", Toast.LENGTH_LONG).show()         }         override fun onResponse(call: Call<AuthResponse>?, response: Response<AuthResponse>?) {             val body = response?.body()             Log.d("Quiz", "Response: $  {response?.code()}")             if (response?.isSuccessful == true) {                 if (body!!.sucesso) {                     val it = Intent(this@AuthFragmentRouterActivity,                     it.putExtra("usuario", Gson().toJson(usuario))                     startActivity(it)                     finish()                 } else Toast.makeText(this@AuthFragmentRouterActivity, body.mensagem, Toast.LENGTH_LONG).show()             } else Toast.makeText(this@AuthFragmentRouterActivity, "Ocorreu um erro.", Toast.LENGTH_LONG).show()         }     }) 

South Korean tourist visa – is funds parking acceptable in my situation?

I’m travelling to South Korea soon with my Korean girlfriend. We both live in a Southeast Asian country of which I am a citizen. I used to lived in Europe till a few months back so I have a bank account there which holds most of my savings. For proving that I have enough funds for the trip, I need to submit a bank statement with transactions from the last 6 months. The problem is that it is impossible for me to get those bank statements stamped by the bank since I’m here.

I also have a bank account in my home country but it barely has had any money since the past 6 months. My girlfriend recently transferred $ 2000 into that account so that I could submit a proper stamped statement from this account as well.

Now I understand that these type of last minute deposits are referred to as ‘funds parking’ and are generally discouraged. But in my situation, since I’m also submitting an unstamped statement from my European bank, will it okay? Is it too suspicious that my gf who is also travelling with me transferred so much money into my account just before my visa appointment?

Acceptable to use synchronous call to another microservice for time-sensitve state change?

Say there are two microservices (example is simplified)

PickupRequestService: lists pick-up requests of passengers

DriverService: drivers use to accept pickup requests

On a completely decoupled communication method (via message queues), DriverService would make an async call to accept a pick-up request e.g., PickupRequestService->accept(pickupId). This looks fine however, for a few seconds, this will cause other drivers to see pick-up requests that are already taken.

You could probably eventually send a compensating failed message for those hopeful drivers that accepted a taken pick-up request e.g., “your request to accept the passenger has been rejected…” but that won’t be a good UX.

My question is, for scenarios similar to this, where a state changing operation is time sensitive, is it okay to make synchronous inter-microservice REST calls? E.g., DriverService synchronously calls PickupRequestService->accept(pickupId) so that the state change is instantaneous and no other driver sees old pick-up requests anymore.