Search
30 results for “wcag”
Search results
What do WCAG's 4.5:1 and 3:1 contrast ratios each apply to, and why does the threshold change for large text?
WCAG 2.1's AA-level contrast requirement is 4.5:1 for normal text, text smaller than 18 point (or 14 point bold), and a relaxed 3:1 for large text at or above that size threshold. The reasoning given is that larger text with wider character strokes is inherently easier to read at lower contrast, so the stricter 4.5:1 ratio is reserved for the smaller, harder-to-read text where insufficient contrast is much more likely to genuinely block reading for people with low vision, color-vision deficiencies, or age-related contrast sensitivity loss. It is not an arbitrary aesthetic distinction, it is calibrated to actual legibility at different sizes.
Web Accessibility Fundamentals
Why the W3C's own first rule of ARIA is to avoid ARIA whenever a native HTML element already does the job, and what WCAG's 4.5:1 versus 3:1 contrast ratios actually apply to.
What is the "first rule of ARIA," and why does a native <button> beat a <div role="button"> even though both can be made accessible?"
The W3C's own first rule of ARIA use is direct: if a native HTML element or attribute already provides the semantics and behavior you need, use it instead of re-purposing a different element with ARIA. A native `<button>` comes with keyboard interaction (Enter/Space activates it, Tab reaches it), focus management, and correct semantics built into the browser for free. A `<div role="button">` requires manually replicating every one of those behaviors with JavaScript and additional ARIA attributes, tabindex, keydown handlers for both Enter and Space, and it is easy to miss an edge case a real button never had in the first place. ARIA can make a div accessible in theory; a native element already is, with less code and less risk.
A custom dropdown built entirely from styled divs passes a visual design review. What is likely still broken for a keyboard-only or screen-reader user, and why doesn't looking right catch it?
Without the correct ARIA roles/states (or, better, a native `<select>`), a div-based dropdown typically has no way to be reached or operated via keyboard alone (no built-in Tab/Enter/Arrow-key handling), and a screen reader has no semantic information telling it "this is a dropdown, it is currently closed, here are its options," so it may announce nothing meaningful at all. A purely visual review can't catch this because the div looks and behaves correctly with a mouse, the missing behavior only surfaces via keyboard navigation or assistive technology, which is exactly why accessibility has to be tested directly with a keyboard and a screen reader, not inferred from how a component looks.
What is the difference between a security group and a network ACL in a VPC?
A security group is stateful and attaches at the instance/ENI level: it only supports allow rules, and if inbound traffic is allowed, the corresponding response traffic is automatically allowed back out regardless of outbound rules. A network ACL is stateless and attaches at the subnet level: it supports both explicit allow and explicit deny rules, numbered and evaluated in order starting from the lowest number, and because it has no memory of prior traffic, allowing inbound traffic does not automatically allow the matching outbound response, that has to be permitted by its own rule. Security groups are the primary, fine-grained access control per resource; network ACLs are a coarser, optional second layer at the subnet boundary.
When would you choose Azure App Service over a Virtual Machine for hosting a web application?
App Service is a fully managed PaaS; it handles OS patching, runtime installation, and built-in scaling and deployment slots, so you only manage application code and configuration. A Virtual Machine is IaaS, full control over the OS and everything installed on it, but you own patching, scaling configuration, and availability yourself. Choose App Service when the workload is a standard web app/API in a supported runtime and the team wants to minimize operational burden; choose a VM when you need OS-level control, unsupported runtimes/dependencies, or specific compliance requirements that mandate managing the host directly.
What is the difference between a resource group and a subscription in Azure?
A subscription is a billing and access-management boundary; it's tied to an agreement with Microsoft, has its own spending limits and quotas, and is typically the unit organizations use to separate environments (production vs. non-production) or business units. A resource group is a logical container inside a subscription that groups related resources (a VM, its disks, its network interface) that share the same lifecycle, created and deleted together. Deleting a resource group deletes everything in it, which makes resource groups the practical unit of "this is one deployable thing," while subscriptions are the practical unit of "this is one billing and governance boundary."
What is the difference between VNet peering and a VPN gateway?
VNet peering connects two VNets directly over Microsoft's backbone network, low latency, high bandwidth, no gateway required, but both VNets need non-overlapping address spaces and peering doesn't transit by default (VNet A peered to B, and B peered to C, doesn't mean A can reach C without its own peering). A VPN gateway creates an encrypted tunnel, typically used to connect an on-premises network to Azure, or between Azure and another cloud, over the public internet rather than Azure's internal backbone. Peering is for Azure-to-Azure connectivity at the best possible performance; a VPN gateway is for connecting to networks outside Azure, or when encryption over the transport itself is a specific requirement.
What is the difference between a security group and a network ACL?
A security group is stateful and attached to individual resources (like an instance or load balancer), if you allow inbound traffic on a port, the corresponding outbound response is automatically allowed, and rules are evaluated as an allow-list only. A network ACL is stateless and attached to a subnet, evaluating both inbound and outbound rules independently for every packet, including explicit deny rules. Security groups are the primary, more commonly used tool for per-resource access control; network ACLs add a coarser, subnet-wide layer, often left at their permissive default and used mainly for defense-in-depth or to explicitly block something.
What is the difference between `git reset` and `git revert`, and when should you use each?
git reset moves the current branch pointer (and optionally the staging area and working directory) to a different commit, effectively rewriting history as if the reset-past commits never happened on this branch - fine for commits that only exist locally and haven't been pushed. git revert creates a brand new commit that applies the inverse of a previous commit's changes, leaving history intact and additive. Because it doesn't rewrite anything, revert is the safe choice for undoing a commit that's already been pushed and pulled by others; reset --hard on shared history causes exactly the same divergence problem as a rebase on a shared branch.
What does "at-least-once delivery" actually guarantee, and what does it not guarantee, and why does that mean a consumer must be idempotent?
At-least-once delivery guarantees a message will eventually be delivered and processed at least one time, it does not guarantee exactly one delivery, the same message can legitimately be delivered and processed more than once, for example if a consumer's deletion request is lost after it already finished processing, or a visibility timeout expires just as processing completes. Because duplicate delivery is a normal, expected outcome of this model rather than a rare edge case, a consumer has to be written so that processing the same message twice produces the same end result as processing it once (an idempotent operation), rather than assuming the queue itself will prevent duplicates.
Why does the choice between WSGI and ASGI matter when picking a Python web framework?
WSGI (Web Server Gateway Interface) is the traditional, synchronous interface between Python web applications and servers, one request is handled by one worker thread/process at a time, blocking for its duration. ASGI (Asynchronous Server Gateway Interface) extends that to support async request handling and other async protocols (WebSockets), letting a single worker handle many concurrent requests while they're waiting on I/O, the same underlying model as asyncio generally. Flask and Django historically are WSGI (Django has gained ASGI support); FastAPI is ASGI-native. The choice matters because it determines whether the framework can actually benefit from async I/O concurrency, or whether it's fundamentally a one-request-per-worker model regardless of async syntax used inside a handler.
Why does a chunk like "The company's revenue grew by 3% over the previous quarter" cause a retrieval failure even if it's embedded correctly?
That sentence is only meaningful with context the isolated chunk doesn't carry, which company, which quarter, information that likely lived in a heading or preceding paragraph that didn't survive the chunking boundary. Embedded on its own, the chunk's vector represents a generic, context-free statement about revenue growth, which means it won't be retrieved reliably for a query about "ACME Corp Q2 2023 earnings" even though it's exactly the right chunk, because nothing in its embedding actually encodes that it's about ACME Corp or Q2 2023 at all.
Why are environment variables considered a weaker place to store a secret than a dedicated secrets manager, even though they avoid hardcoding it in source?
Environment variables are readable by the entire process (and often child processes) they're set for, commonly get dumped into crash reports, debugging output, or `/proc` on Linux, and are easy to accidentally log in full, none of which requires a targeted attack, just an ordinary operational mistake. A dedicated secrets manager instead requires an authenticated, audited API call to retrieve a secret, can issue it as short-lived, and centralizes rotation and access logging in one place. Environment variables are a real improvement over hardcoding in source, but they are a stopgap, not the same security posture as centralized, audited secret retrieval.
MongoDB can be configured to behave more like a CP system or more like an AP system. What settings make that choice, and what are they actually trading?
Write concern and read preference are the actual levers: a write concern requiring acknowledgment from a majority of replicas favors consistency, a write isn't considered successful until enough nodes agree, at the cost of availability if too many nodes are unreachable during a partition. A looser write concern, or reading from secondaries that might lag behind the primary, favors availability, operations keep succeeding even when full replica agreement isn't achievable, at the cost of potentially reading or acknowledging data that isn't fully consistent across the cluster yet. This is exactly the CP-versus-AP trade-off CAP describes, expressed as a concrete, tunable configuration rather than an abstract theorem.
Why Cloud Tech by Victor Will Never Require a Login
No accounts, no saved progress, no paywall, a look at why Cloud Tech by Victor is built to stay a pure reference, not a platform.
Why can animating transform or opacity skip layout and paint entirely, while animating top or width cannot?
transform and opacity don't change an element's geometry, its size or position in the document flow, or repaint its actual pixel content, they only change how an already-painted layer is displayed (moved, scaled, faded) during compositing. Because nothing about the element's layout or pixels actually changed, the browser can skip straight to the composite stage, the cheapest, fastest path in the pipeline, and handle it on the compositor thread. `top` and `width` do change geometry, so there's no way to skip layout, the browser has no shortcut for "the size changed but skip figuring out the new size."
Why can't partition pruning work with a WHERE clause like WHERE logdate >= CURRENT_TIMESTAMP, and what does that tell you about writing partition-friendly queries?
Partition pruning at plan time requires the comparison value to be known and fixed when the plan is built, and `CURRENT_TIMESTAMP` is not immutable, its value depends on when the query actually executes, not when it's planned, so the planner can't statically prove which partitions it will or won't match. (Pruning can still happen at execution time for genuinely parameterized values, like a join parameter from an outer query, just not for volatile functions like this one.) This means writing partition-friendly queries means filtering on the partition key with values the planner can actually reason about, a literal, a bound parameter, or an immutable expression, not a function whose result varies by when the query runs.
What is the difference between GROUP BY aggregation and a window function like `ROW_NUMBER() OVER (...)`?
`GROUP BY` collapses every row in a group into a single output row per group, you lose access to the individual rows once you've aggregated. A window function computes its result (a rank, a running total, a row number) per row while keeping every individual row in the output, `PARTITION BY` defines the grouping for that calculation, but nothing is collapsed. This is why "give me each order plus that customer's running total" needs a window function, while "give me one row per customer with their total" is a plain `GROUP BY`.
Why does calling a blocking function inside an async function defeat the purpose of using asyncio?
A blocking call (synchronous file I/O, a synchronous HTTP request, `time.sleep`) occupies the single thread the event loop runs on, and unlike `await`, it does not yield control back, the entire event loop is frozen for the duration of that blocking call, so every other coroutine that could otherwise be making progress is stalled too. This is why async code requires async-compatible libraries throughout the I/O path; a single accidental blocking call anywhere in a hot path can silently serialize what was supposed to be concurrent work, and the bug often doesn't show up until real concurrent load exposes it.
Why does using an array index as a list item's key cause state to attach to the wrong item once the list is reordered, and what's the fix?
With `key={i}`, React tracks each item's state by its position in the array, not by which real-world item it represents, so after reversing a list, the state that was originally at index 0 (say, an "expanded" toggle on the first item) stays at index 0 and now renders alongside whatever item ended up there after the reorder, not the original item it belonged to. The fix is using a stable, unique identifier from the actual data, `key={contact.id}`, so React can match each item to its correct state across renders regardless of how the list is reordered, added to, or filtered, rather than relying on a position that can shift under the data.
Why is caching harder with GraphQL than REST?
REST responses map naturally to HTTP caching because a GET to a specific URL returns a predictable resource, so CDNs and browsers can cache by URL. GraphQL typically uses a single POST endpoint with a query body, which defeats standard HTTP/URL-based caching, most GraphQL setups instead rely on client-side normalized caches (like Apollo Client or Relay) keyed by object id and field, or persisted queries plus a CDN cache keyed on the query hash.
Why is the CAP theorem often described as "choose two of three," and why is that framing slightly misleading?
The framing suggests a system designer picks any two of consistency, availability, and partition tolerance as a free, standing choice, but partition tolerance isn't actually optional for a real distributed system, network partitions happen (a link fails, a node becomes unreachable), so a system that "chooses" not to tolerate partitions simply isn't distributed in any meaningful sense once one occurs. The real choice CAP describes is narrower and only activates during an actual partition: when nodes can't communicate, do you keep responding and risk inconsistency (AP), or do you pause and refuse some requests to guarantee consistency (CP)? Outside of an actual partition, a well-designed system can be both consistent and available; CAP is a statement about what happens specifically during a partition, not a permanent, constant trade-off.
When would you use a CloudWatch alarm versus digging into CloudWatch Logs Insights?
A CloudWatch alarm watches a metric against a threshold and is the right tool for fast, simple, near-real-time detection, error rate crossing 5%, latency crossing a p99 target. CloudWatch Logs Insights is a query language for ad hoc investigation of the underlying log data, the tool for answering a specific question an alarm was never built to ask, like "which requests failed, and what did they have in common." Alarms are for detecting that something is wrong quickly; Logs Insights is for actually finding out why once an alarm (or a user report) says something is.
What does an EC2 Auto Scaling Group actually manage, and why does the scaling metric choice matter?
An Auto Scaling Group keeps a fleet of EC2 instances at a desired size, launching or terminating instances automatically based on configured scaling policies, and replacing instances that fail health checks, so nobody is manually adding or removing servers as load changes. The scaling metric determines whether that automation actually tracks the real bottleneck: scaling purely on CPU utilization looks like "autoscaling is working" on a dashboard while a memory-bound or queue-depth-bound workload keeps falling behind, because the metric driving the scaling policy never reflected the actual constraint. Choosing a metric (or combination of metrics, including custom CloudWatch metrics) that matches the workload's real bottleneck is what makes the automation actually correct rather than just present.
What is a Service Control Policy (SCP), and what is the one thing it does not do?
An SCP is a policy attached to an AWS Organizations root, organizational unit, or member account that defines the maximum available permissions for every identity in that account, including that account's own administrators and its root user. What an SCP does not do is grant any permission by itself, it only sets a ceiling; an identity still needs an actual IAM allow (from an identity-based or resource-based policy) within that ceiling to do anything. An SCP with no matching IAM allow underneath it results in access denied, not access granted, which is the most common misunderstanding of how SCPs work. One exception worth knowing: SCPs never apply to the organization's management account itself, only to member accounts.
If VPC A is peered with VPC B, and VPC B is peered with VPC C, can A reach C through B?
No. AWS VPC peering connections are explicitly non-transitive: a peering connection is a strict one-to-one relationship between exactly two VPCs, and you cannot use one VPC as a transit point for another peering connection it happens to also have. To let A reach C, a separate, direct peering connection between A and C has to be created; there is no way to route through B. A Transit Gateway, not a mesh of peering connections, is the AWS-recommended way to connect more than a couple of VPCs that all need to reach each other.
What is the difference between a metric alert and a log alert in Azure Monitor?
A metric alert evaluates near-real-time numeric metrics (CPU percentage, request count) against a threshold, with low latency, typically triggering within a minute or so of the threshold being crossed. A log alert runs a KQL query against Log Analytics on a schedule (e.g., every 5 minutes) and alerts based on the query's results, which supports much richer conditions (joining multiple data sources, complex filtering) but has higher latency, bounded by both the query schedule and log ingestion delay. Choose metric alerts for fast-reacting, simple threshold conditions, and log alerts for anything requiring more complex logic than a single metric can express.
What are the five stages of the browser rendering pipeline, and which ones does a change to a property like width actually have to go through?
The pipeline runs JavaScript, Style calculation, Layout, Paint, and Composite, in that order. Changing a property that affects geometry, `width`, `height`, `position`, forces the browser through every stage: layout has to be recalculated (since the element's size or position changed), then paint (since pixels changed), then composite. That full path is why layout-affecting properties are the most expensive to animate, every frame re-runs the whole pipeline, not just a cheap final step.
Why might a team deliberately choose IaaS over PaaS even though PaaS requires less operational work?
PaaS trades control for convenience; it constrains you to whatever runtimes, configurations, and scaling behavior the platform supports. Teams choose IaaS when they need capabilities a PaaS doesn't expose (custom OS-level tuning, unusual networking topologies, specific compliance requirements that mandate control over the underlying host), when they're running workloads a PaaS wasn't designed for, or when the cost model of many small PaaS instances doesn't make sense at their scale compared to self-managed infrastructure.