Local focus in ArcGIS Online — the three properties Map Viewer saves into the web map, and the two places they stop

You have median home value by county for the whole United States on the map, and the point you are making is about Missouri. Drop the other forty-nine states with a filter and the reader loses the comparison that made Missouri worth pointing at. Leave them at full strength and there is nothing to point at. So you reach for the third option: keep every county on the map, and make one state the only part of it that looks alive.

That is what Esri’s own sample map does, and the expression it does it with is ST_ABBREV = 'MO'. What is worth an article is not the effect — it takes about ninety seconds in the Effects pane — but what happens to it afterwards. The focus is not baked into an image and it is not written into your data. It is saved into the web map item as a small set of presentation properties, and from that moment its fate depends entirely on what reads the item next. Some paths read those properties and reproduce your focus. Two documented paths drop it: a 3D scene, and the print service most maps eventually go through.

Everything below was verified on September 28, 2026 against ArcGIS Maps SDK for JavaScript 5.0.19 — the version the js.arcgis.com/5.0/ entry point resolves to, and the one this site pins — and against web map specification 2.37. Note the version drift already in progress: the reference pages linked at the end sit under /javascript/latest/, and latest now serves v5.1 (the npm latest tag on @arcgis/core is 5.1.25). The quoted sentences were re-read on that date; a /latest/ URL is not a pinned version and should never be treated as one.

Three properties, not two

The Map Viewer controls that produce a local focus live in two different panes, and between them they write three different web map properties. Conflating any two of them is the first way this goes wrong.

That reach asymmetry is not a footnote. A reader who has absorbed “effects are a layer property” will sooner or later try a feature-specific effect on a vector tile basemap, because the Effects pane looks like one control with a toggle at the top of it. It is one pane over two properties, and only the whole-layer one goes anywhere near a basemap.

The Effects pane itself says which mode you are in: “At the top of the Effects pane, ensure that Whole layer is selected” against “ensure that Feature-specific is selected”. Whole layer offers nine effects — Bloom, Drop shadow, Blur, Brightness & Contrast, Grayscale, Hue rotate, Saturate, Invert and Sepia. Feature-specific offers nine presets instead: Drop Shadow + Gray, Strong Drop Shadow, Drop Shadow + Transparency, Drop Shadow + Blur, Muted Blur, Muted Grayscale, Bloom + Gray, Bloom + Blur and Bloom + Transparency — and the pane groups them by whether Esri recommends them for dark or light backgrounds. Choosing one does not leave you at a preset: “The map updates to show the effect with a default filter expression applied”, and you then edit that expression. The condition is authored inside the effect.

Blending is the other half. Map Viewer “includes more than 30 unique blend modes that you can apply and instantly see reflected on the map”, organized by theme: 30 named modes across Lighten, Darken, Contrast, Component, Compositing and Invert, plus the default Normal. Thirty-one persisted values, which is exactly the count the web map specification lists.

The Compositing family is the one that makes a cookie-cutter focus possible, and two of its members look alike and are not. Destination In: “The destination (background) layer is drawn only where it overlaps the top layer. Everything else is made transparent.” Destination Atop does that and two more things — “The top layer is drawn under the background layer, and the top layer shows through wherever the background layer is transparent or has no data”. Esri’s campus sample uses Destination Atop; its country and corridor samples use Destination In.

Two things are true of both controls, and they matter more than any individual setting. First, they are presentation only — “When you apply a blend mode, there is no change to the data or to the original rendering of the layers”, and the effects help page says the same of effects. Second, they persist: “When you save the map, the blend mode is saved to the map”. One documented exclusion is worth knowing before you build anything on this: feature-specific effects are “not supported for layers where clustering has been enabled”. And one documented inclusion that surprises people: effects are not vector-only — “Effects can be applied to points, lines, and areas, and can also be applied to raster and imagery layers.”

What Map Viewer actually writes into the web map

Every claim in this section came from fetching the saved JSON of Esri’s own public sample maps — /sharing/rest/content/items/<id>/data?f=json — and reading the operational layers. The State & County Focus map, item a3e416b2185c4328b74e65fe628288b0, stores its focus like this — abridged, since the same layer also carries id, itemId, url and layerDefinition:

{
  "title": "Median Home Value 2026",
  "layerType": "ArcGISFeatureLayer",
  "effect": null,
  "featureEffect": {
    "filter": { "where": "ST_ABBREV = 'MO'" },
    "includedEffect": [
      { "type": "drop-shadow", "xoffset": 1.5, "yoffset": 1.5,
        "blurRadius": 2.25, "color": [50, 50, 50, 255] }
    ],
    "excludedEffect": [
      { "type": "grayscale", "amount": 1 },
      { "type": "opacity", "amount": 0.5 }
    ]
  }
}

That is the whole mechanism in one object. A where clause splits the layer in two: one list of effects is applied to the features that satisfy it, and a different list to the features that do not. The specification is exact about the shape: featureEffect has three properties — filter, includedEffect, excludedEffect — and its filter object has exactly one, “where — A SQL-based where clause that narrows the data to be used”. There is no geometry property. A spatial focus is not something a saved web map can carry here.

Three things about that JSON surprise people who have only used the SDK.

An effect in the web map is an array of typed objects, not a string. The specification allows “Effect Functions[]… Scale Dependent Effect[]… null”, with [{"type":"brightness","amount":4}] as its own example. The JavaScript SDK spells the same concept as a CSS-filter-like string ("grayscale(100%) opacity(50%)"). Same idea, two serializations — and they are not interchangeable.

The filter can be null. Two of Esri’s own saved maps persist "filter": null alongside a populated includedEffect and excludedEffect. So the safe statement is that a persisted feature effect may carry a where clause, not that it must. What such an object does when it renders — whether every feature counts as included or as excluded — is not something the documentation settles, and this article does not settle it either. It is an observation about saved JSON, not a behavior claim.

A layer filter and a feature effect are different things and can sit on the same layer. The Country Focus map carries layerDefinition.definitionExpression: "COUNTRY = 'Italy'" — a real filter, which “narrows the data to be displayed in the layer” — and a featureEffect whose filter is null, and blendMode: destination-in, all on one layer. If you have never seen those three coexist, the saved JSON is the fastest way to understand that they are independent levers. Which of them to reach for, and what each does to the feature count you quote back to a user, is the subject of an earlier post on this blog; this one is about what the web map stores.

Two shape details that bite later. includedEffect and excludedEffect are not always flat arrays — the specification documents a scale-dependent form for them too, and the interpolation rule is on the effect object page rather than the feature effect one: “Effects are interpolated between each scale stops”. What a scale-dependent effect cannot do is change shape between its own stops, and it is the SDK’s FeatureEffect reference rather than the specification that says so — “The type and order of effects should be consistent at all scales so that they can be interpolated. If the type and order are not consistent, the effect will be set to null, and a warning will be shown in the console.” Not a degraded result. No effect at all. The two forms do coexist: Esri’s own valid example pairs a scale-dependent includedEffect with a flat string excludedEffect in one feature effect.

The scale-dependent form is also why a saved map can look more complicated than the blog post that describes it. Esri’s Camp Fire focus map stores its bloom as three scale stops, not one setting. Bloom and Drop shadow both offer Automatically adjust based on scale, worded “Turn off this option to keep the effect the same regardless of map scale” — phrasing that implies it is on by default. The three saved stops are consistent with that, though no page states the causal link. Esri’s post quotes Strength 2.2, Radius 0.6, Threshold 10. Threshold 10 is the pane’s percent form of the JSON’s 0.1, since bloom threshold “Accepted values are 0%-100% or 0-1”, and Strength 2.2 is the middle of the three saved strengths. Only Radius 0.6 matches none of the saved radii (0.225, 0.45, 0.9).

One thing you will not find, and should stop looking for: a minimum specification version. The object pages carry no “added in” column and there is no version-history page under the specification. The version numbers that are anchorable are the SDK’s, and they must be labeled as SDK versions, never as specification versions. For reference, current maps are being saved at 2.37 — four of the five Esri samples behind this article report 2.37, and the Country Focus map is still at 2.25.

Why the group layer is what makes it local

Blending composites a layer against what is below it. On a map with five layers that means it composites against all of them, which is rarely what a focus map wants. A group layer is how you scope it — and the sentence that says so is not where an ArcGIS Online author would look for it.

The web map specification’s group layer object states the rule: “With respect to layer blending, sublayers of a group layer are blended together in isolation, separate from layers outside that group layer. When blendMode is specified for a group layer, the group’s collective content is blended with the layer underneath.” The JavaScript SDK states it independently: “The layers in a GroupLayer are blended together in isolation from the rest of the map.”

The ArcGIS Online help page on blend modes does not. The word group does not appear on it at all. That is not a complaint about Esri’s documentation so much as a warning about research technique: if your sources are the Map Viewer help pages — a perfectly reasonable place for a Map Viewer question to start — the single rule that makes this technique controllable is invisible to you. It is written down in the developer reference for a specification you are authoring by clicking.

Note what the rule does and does not say. It does not say a group layer is required. Without one the blend still runs — it simply composites against everything below it in the map. What the group buys you is scope, and Esri’s own Wilshire Corridor sample shows it: a destination-in buffer layer inside the focus group, and a second, normal-mode copy of the same buffer outside it. The group is what makes the focus local; it is not a precondition for the property to function.

Order inside the group is a precondition, and it is the easiest thing to get backwards. Index 0 is the bottom: “The first layer added is always the base layer, even if its order is changed.” Destination In draws the background layer only where it overlaps the top layer, so the mask has to be last in the list, not first. Both of Esri’s saved group-layer samples — Country Focus and Wilshire Corridor — agree: index 0 is World Imagery, index 1 is the destination-in mask.

One more thing about the mask, since it is the part with no documentation to lean on: the mask’s geometry decides what the reader sees of the layer underneath, so its provenance is an editorial claim your map is making. Esri’s campus example is explicit that the boundary came from a sketch — “a sketch layer was added to the map and a polygon was drawn around the Esri Redlands campus boundary”. A hand-drawn polygon is a fine mask and a poor authority. If the shape means something — a service area, a jurisdiction, a permit boundary — say where it came from.

Finally, a completeness note for anyone debugging a blend that looks wrong. The SDK lists what actually feeds the result: “Order of all layers / Layer opacity / Opacity of features in layers / Visibility of layers”, plus “By default, the very bottom layer in a map is drawn on a transparent background.” A blend mode is never the only input.

One consequence of that list is worth its own sentence, because it is the failure a team hits in week two. destination-in draws the background only where the mask overlaps it. So when the mask is not drawn — a scale range on the mask layer, or a reader turning it off in the Layers list — the group composites against nothing and goes blank, with no error anywhere. Visibility of layers is on the list above for exactly this reason. In a map you build from code the documented lever is GroupLayer.visibilityMode set to inherited — “Each child layer’s visibility matches the GroupLayer’s visibility” — which takes the mask out of the reader’s reach. That lever does not survive a save. The web map specification’s group layer object accepts exclusive and independent and nothing else, so a Map Viewer author is left with the blunter versions: give the mask no scale range, and keep it out of a layer list a reader can toggle.

What the JavaScript SDK reads back

The properties come from two mixins. BlendLayer supplies blendMode and effect; FeatureEffectLayer supplies featureEffect. In 5.0.19, FeatureLayer mixes in both, so all three properties exist on it; GroupLayer mixes in BlendLayer, which is why a group can carry a blend mode of its own. The introduction versions, taken from the shipped type declarations and stated as SDK versions: BlendLayer at 4.17, blendMode at 4.16 with default "normal", effect at 4.18, featureEffect at 4.22.

Does a WebMap loaded by portal item id actually read your authored focus back out? The shipped property descriptors say so. This is the compiled accessor metadata from @arcgis/core@5.0.19, quoted as code because that is what it is — not a documentation sentence:

layers/mixins/BlendLayer.js   blendMode
  json: { read: !1, write: !1, origins: {
    "web-map":     { read: !0, write: { layerContainerTypes: t } },
    "portal-item": { read: !0, write: { layerContainerTypes: t } } } }

layers/mixins/FeatureEffectLayer.js   featureEffect
  s = { write: { allowNull: !0 } }
  p = { type: o, json: { origins: { "web-map": s, "portal-item": s } } }

Both origins are present on both properties, which is the mechanism behind “the focus travels with the item.” Be precise about how far that statement reaches: it is verified here for ArcGIS Online Map Viewer, which authors the properties, and for the JavaScript SDK 5.x in a 2D MapView, which reads them. It is not a general claim about every ArcGIS client, and the next section explains why.

If you are writing this from code rather than clicking it, four rules decide whether it works. The code below is doc-anchored — fragments, not a runnable demo; nothing in it was executed in a browser in the course of this article, and it is not offered as a working sample.

One. The four presentation properties compose in a fixed order: “If all of the following four properties are applied, then they will be applied in this order: featureEffect, effect, opacity and blendMode.” Reasoning about a surprising result without that order in front of you is guesswork.

Two. A layer effect is inherited by the layer view, and the layer view wins if you set both: “The layerView.featureEffect will take precedence over layer.featureEffect if both properties are set.” But a layer view effect is a dead end for persistence — “A FeatureEffect set on a layerView cannot persisted in a WebMap” (the typo is Esri’s). Set it on the layer.

Three. Persisting a feature effect from code has two further conditions beyond setting it on the layer: an attribute-only filter, and excludedLabelsVisible set to true — “This property must be set to true in order to persist the FeatureEffect to a WebMap”, and its default is false. Why each is required is already written up in detail in the earlier post linked in the references, so this one will not re-derive it.

Four, and this is the trap: do not copy Esri’s own feature effect examples into a workflow that saves. The lead class-level example on each of the two pages — FeatureEffect and FeatureEffectLayer, so the first example a reader meets on either — builds a spatial filter: geometry, spatialRelationship, distance, units. The FeatureEffect page’s own rule disqualifies them: “A FeatureEffect can only be persisted to a WebMap if an attribute filter is the only property set on FeatureFilter.” The FeatureEffectLayer page carries the spatial example and not the rule, which makes the trap easier to fall into rather than harder. Copy either one into a workflow that saves and the effect does not persist. An attribute-only filter, in the shape the reference licenses, looks like this:

// Doc-anchored fragment, not an executed sample. Assumes <div id="viewDiv"> on the
// page and the 5.0 CDN entry loaded in a <script type="module">.
const [WebMap, MapView, FeatureEffect, FeatureFilter] = await $arcgis.import([
  "@arcgis/core/WebMap.js",
  "@arcgis/core/views/MapView.js",
  "@arcgis/core/layers/support/FeatureEffect.js",
  "@arcgis/core/layers/support/FeatureFilter.js",
]);

const map = new WebMap({ portalItem: { id: "a3e416b2185c4328b74e65fe628288b0" } });
const view = new MapView({ container: "viewDiv", map });
await view.when();

const counties = map.layers.find((layer) => layer.title === "Median Home Value 2026");
if (!counties) throw new Error("no layer titled Median Home Value 2026 in this map");

// Attribute filter ONLY -- a spatial FeatureFilter renders fine and will not persist.
counties.featureEffect = new FeatureEffect({
  filter: new FeatureFilter({ where: "ST_ABBREV = 'MO'" }),
  includedEffect: "drop-shadow(1.5px, 1.5px, 2.25px, #323232)",
  excludedEffect: "grayscale(100%) opacity(50%)",
  // Second persistence condition, and false by default -- without it the effect
  // renders, the save succeeds, and featureEffect is absent from the saved item.
  excludedLabelsVisible: true,
});

Note the string form of the effects there, against the array form in the saved web map earlier in this article. That is the same serialization split as before, in the one place it is most likely to catch you. The SDK supports eleven effect functions — “bloom, blur, brightness, contrast, drop-shadow, grayscale, hue-rotate, invert, opacity, saturate and sepia” — and the string syntax is CSS-filter-like rather than CSS filter: no url(), absolute length units only, and a bloom function CSS does not have.

And a mask layer in a group, expressed the same way — with the layer order that Esri’s saved maps use, mask last:

// Doc-anchored fragment, not an executed sample.
const [GroupLayer, FeatureLayer, TileLayer] = await $arcgis.import([
  "@arcgis/core/layers/GroupLayer.js",
  "@arcgis/core/layers/FeatureLayer.js",
  "@arcgis/core/layers/TileLayer.js",
]);

const imagery = new TileLayer({
  url: "https://services.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer",
});

const mask = new FeatureLayer({
  portalItem: { id: "2b93b06dc0dc4e809d3c8db5cb96ba69" }, // World Countries Generalized
  definitionExpression: "COUNTRY = 'Italy'",              // a LAYER filter, not the effect filter
  blendMode: "destination-in",
  renderer: {
    type: "simple",
    symbol: { type: "simple-fill", color: [255, 255, 255, 1], outline: null },
  },
});

// Index 0 is the BOTTOM of a GroupLayer: "The first layer added is always the base layer,
// even if its order is changed." destination-in needs the mask ON TOP, so it goes last.
const focusGroup = new GroupLayer({
  title: "Country Focus",
  layers: [imagery, mask],
  visibilityMode: "inherited",   // SDK-side only -- the web map spec takes only
                                 // "exclusive" or "independent"
});

// Nothing composites until the group is in the map. Illustration only: read map here as
// whichever map the Italy focus belongs to, not as the Missouri WebMap fragment above.
map.add(focusGroup);

The mask’s symbol is doing real work there, and the guidance for it is Esri blog advice rather than a reference rule: “for best results, the polygon you are using for the mask should be styled using a solid fill and no transparency. An outline is not necessary.” A partly transparent mask composites partly, which reads as a bug and is not one.

Where the focus stops traveling: the third dimension

There is one place the properties provably do not follow the item, and it is documented without ambiguity. FeatureEffect is described as a 2D capability in its first sentence — “FeatureEffect allows you to emphasize or deemphasize features that satisfy a filter in 2D MapView” — and both effect properties carry the same exclusion: “FeatureEffect is not supported in the following scenarios: In 3D SceneViews”, and “The effect is not supported in 3D SceneViews.”

Blend modes are the interesting case, because the tidy version of this rule — blending and effects are 2D-only — is false. Blend modes work in 3D, on a named list: “In 3D SceneViews, the blendMode is supported on BaseTileLayer, ImageryTileLayer, OpenStreetMapLayer, TileLayer, VectorTileLayer, WCSLayer, WebTileLayer, WMTSLayer and GroupLayer.” Nine layer types. FeatureLayer is not one of them — and in a local-focus map the mask is a feature layer. So the technique does not reach a scene even though the property it is built on partly does, and inside a 3D group layer the rule narrows again: “the blendMode is only applied to the sublayers that support it.”

One smaller omission in the same family, worth a line because it shows up in screenshots rather than in errors: “The blendMode is not supported in the Legend.”

The print path: two different failures, and only one of them is obvious

This is where a focus map most often dies, and it dies quietly. Map Viewer’s own Print tool documents it plainly: “Layers configured with any of the following will print as if those configurations are not applied: Group layers using layer blending or effects; Layers with a combination of both blending and effects; Layers with any of the following blend modes applied: Average, Destination Atop, Destination In, Destination Out, Destination Over, Invert, Lighter, Minus, Plus, Reflect, Source Atop, Source In, Source Out, Vivid Light, XOR…” The quoted list runs on past the blend modes to three more configurations — value-order symbology, Above and Below renderer themes, and imagery layers with a pixel filter. The JavaScript SDK’s print module says the same in its own words: “There is no current support for printing GroupLayers with blending or effects.”

Read that list against the technique. Destination In is on it. Destination Atop is on it. The group layer that made the focus local is on it. Every ingredient of a masked local-focus map is on that list, which means the print does not come out soft or approximate — the focus is simply not there. The map prints as though you never applied any of it.

That first failure is obvious the moment you open the PDF. The second is not. “It does not print” is only true for half the technique, and merging the two halves costs you the more interesting failure. A plain, non-grouped feature layer carrying nothing but a featureEffect — the Missouri map at the top of this article — is not on that list. It prints. It prints badly, in a way that is worth understanding:

• At screen resolution — this one from the SDK’s print module rather than the Map Viewer help page the other three come from. “Printing layers using effects will create a client-side image of the layer in the printout.” The layer is rasterized by the browser and pasted into an otherwise print-DPI page.
• Without its legend. “Legends are not supported for layers with the following configurations: Effects, Binning, Pie chart renderer.”
• Possibly clipped. “Parts of the print output may be cut off when printing with the following configurations if the Show print area toggle button is not turned on: Effects…”
• Without rotated symbols. “Symbols will not appear rotated with the map in the print output for layers with the following configurations: Effects…”

Sixteen blend modes do survive the trip on the SDK print path — the Map Viewer help publishes no positive list of its own — and they are the tonal ones rather than the compositing ones: “color-burn, color-dodge, color, darken, difference, exclusion, hard-light, hue, lighten, luminosity, multiply, normal, overlay, saturation, screen, soft-light” — and “Printing layers with supported blendModes requires ArcGIS Server 10.9.1 or later”, which is a server-version dependency that will move under you eventually. If a focus has to survive print, it has to be built from that list, which rules out the cookie-cutter mask entirely.

A note on what these two lists do and do not prove together. They are near-identical in content, which is strong circumstantial evidence that Map Viewer’s Print tool is the same export service the SDK’s print module drives — but no page read for this article states that identity, so this article does not assert it. What the quotes support is the useful part anyway: both documented ArcGIS print paths carry near-identical exclusions, and every ingredient of a masked local-focus map is on both. They are not identical — the Map Viewer page names one configuration the SDK page does not put on its no-support list (Display features by value order), and the SDK page names two that are not layer configurations at all (SceneViews, and ArcMap-published print services) — but nothing in the gap between them rescues a group layer using blending. Neither print path quietly works.

What does carry it

Naming the paths that lose a thing and none that keeps it is only half an answer, and Esri does not leave it there either. The print module sentence quoted above continues: “Instead, see MapView.takeScreenshot().” That call captures the canvas itself — “Screenshots include only elements that are rendered on the canvas (all geographical elements), but excludes overlaid DOM elements (UI, popups, measurement labels, etc.)” — which is where a blend composite and an effect are drawn. The caveats are the DOM ones: nothing overlaid comes with it, so no legend and no UI, and “Screenshots are always taken inside the padded area of the view.” Resolution is yours to set — width and height are options on the call, and Esri’s own example takes a 2048 by 2048 one. If the deliverable is an image, start there.

If it has to be a paper page, the print-safe shape of this technique is not a cookie-cutter mask at all. A scrim is one semi-transparent polygon covering everything except the focus area, left at normal blend mode, with no effect on any layer and no group layer. Nothing in that description appears on either exclusion list, and normal is on the sixteen-mode survivor list quoted above. It is a weaker illusion than a true mask. It is also the version that arrives in the PDF.

That second failure mode also refines something published earlier on this blog. The ATS post on blocky PDF exports explains that the export service re-fetches each layer server-side at the DPI you request and composites a crisp output — which is accurate. What it does not name is the exception class: a layer carrying an effect is exempted from that server-side re-fetch and is sent up as a client-side image instead. It lands in the crisp PDF at screen resolution. If you have read that post and are still getting a blocky layer, an effect is the first thing to check.

The accessibility bill

Every version of local focus conveys “this is the part that matters” through color treatment alone — grayscale, reduced opacity, a glow. That puts the whole pattern directly under WCAG 2.2 SC 1.4.1 Use of Color, which is a Level A criterion: “Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.”

The remedy is cheap and concrete, and it has two halves that are not interchangeable. For a sighted reader with a color vision deficiency or low vision, pair the effect with a cue that survives being desaturated: a visible boundary outline on the focus area, or a legend entry naming the area in words. Those are pixels on a canvas, though, and map features drawn to a canvas are not exposed to assistive technology as features, so they do little for a screen reader user. That half lives in the DOM. Esri’s accessibility page names both of the places it lives. One is the item’s own details — “It is important to consider accessibility standards when selecting item details without missing information…”. The other is the popup: “Formatting the pop-up’s content in a table to improve navigation for screen-readers”. The sentence this map is about Missouri belongs in the web map’s title, summary and description, not only in a callout drawn on the map. A destination-in mask is arguably the worst case in the family, since it does not de-emphasize the surroundings so much as stop drawing them altogether, leaving nothing at all to indicate that anything was masked.

Two more criteria are usually cited here, and both are more arguable than they first look, because both carry exceptions that land squarely on maps. SC 1.4.11 Non-text Contrast (Level AA) asks for 3:1 on “Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.” An excludedEffect of opacity(50%) — the value in Esri’s own sample — halves the effective contrast of every de-emphasized feature, and in a focus map those features are still required to understand the content, since not filtering them out was the entire point. Whether the exception rescues you is a judgment about your particular map, not a box to tick. Muted Blur and Muted Grayscale are the two presets most likely to push excluded content under the floor.

SC 1.4.3 Contrast (Minimum) (Level AA, 4.5:1) is the one people reach for when they see labels drawn over washed-out features. Its Incidental exception covers text and images of text “that are part of a picture that contains significant other visual content”, and a label rendered into a map canvas is exactly the argument that exception was written for. Treat the label contrast floor here as contested rather than settled — and note that whether Map Viewer even leaves excluded labels drawn is not something this article can tell you. The SDK-side property that governs label persistence does not appear in the web map specification’s feature effect object at all — that object has three properties — and it is absent from every feature effect found in Esri’s saved samples.

Esri’s own accessibility guidance for ArcGIS Online offers one genuinely actionable test for this pattern: “When using Map Viewer and Scene Viewer, you can also install a color filter app as a browser extension. These browser extensions filter the view to show how colors might be interpreted by someone with color vision deficiency.” For a map whose entire argument is carried in saturation, that is a five-minute check worth doing before the map ships.

One last observation, offered as an observation rather than as anything Esri states. Esri’s flagship sample is a graduated-color map of median home value, and its excludedEffect is grayscale at full strength. On a map whose colors are the data, grayscale does not de-emphasize the excluded counties; it deletes their encoding. The legend still describes a color ramp that no longer appears anywhere outside the focus area. If the layer you are focusing is a color-encoded one, opacity de-emphasizes and grayscale erases, and the legend is the thing that gives it away.

Cost, entitlement, and the December 2026 question

The three properties themselves are not credit-metered. The ArcGIS Online credits page does not mention blending, effects or styling anywhere, and its framing sentence covers the case: “Most of what you do in ArcGIS Online does not require credits—for example, using ArcGIS Living Atlas of the World basemaps and imagery, exporting data, and performing single address or place searches.” That is a statement about the properties. It is not a statement about the workflow, and three separate meters sit around it.

The mask can cost credits before any blend mode is applied. Esri’s own Wilshire Corridor sample masks with a layer titled Wilshire Boulevard 1 Mile Buffer. A reader who does not already have a mask polygon has to make one, and making one in Map Viewer is feature analysis: “Create Buffers | Spatial Analysis | 1 credit per 1,000 features”. Keeping the result is metered as well — “There are three types of storage that consume credits: feature storage, imagery storage, and file storage”. Small money, and not zero.

And there is one question to settle before a focus map on Esri demographics is shared publicly. The credits page carries a row naming the content class this article’s worked example draws on: “Demographic maps and layers | Pan and zoom a map containing Esri demographic data… | 10 credits per 1,000 map requests (pan, zoom, and identify)”. Whether that row bills against USA_Latest_Esri_Demographics in particular is not something this article can settle: the item returns access: public with no subscription keyword, and the row’s own example names a different product. It matters because this whole technique deliberately keeps the full national dataset on the map so the reader can compare — which is an invitation to pan, zoom and identify. Ask your administrator before the map is public, not after the statement arrives.

Saving it has an account requirement that the help page states softly. “Confirm that you are signed in and… that you have privileges to create, update, and delete content” is true, and it does not tell a reader whether they personally can do this. The user type page does, and three of its six user types cannot: “Viewers cannot create, edit, share, or perform analysis on items or data”, “Contributors cannot analyze, create, or share items or data”, and the same sentence again for Mobile Workers. What this needs is Creator or above — “Creator — Creators can create and edit content such as maps and apps,… and collaborate and share content for use in apps.” If your organization issued you a Viewer, you can build this map and you cannot keep it — and cannot analyze rules all three of those types out of making the mask as well.

The print path carries a charge of its own, and its scope is narrow — “Printing from custom layout templates | Print a map in Map Viewer. | 5 credits per print job”. Read the scope: custom layout templates, which have to exist first. “If your organization has configured custom print layout templates, those templates are available in the Organization templates section…” Printing on a default template is free, and a reader who needs a custom layout may need an administrator they do not control.

Of the Living Atlas content the source post mentions, exactly one item is subscriber content — and it is not referenced by any of the five saved sample maps. World Traffic Service, whose item keywords carry Requires Subscription and whose license text reads “this item requires an ArcGIS Online organizational subscription or an ArcGIS Developer account and does not consume credits.” Read that last clause twice. Subscriber content and credit cost are independent axes, and conflating them is how budget conversations go wrong in both directions. World Imagery, World Countries Generalized and the current USA Esri Demographics service all return as public with no subscription keyword.

Which brings up the question anyone building on Esri demographics should be asking this quarter. Esri has announced a retirement: “Beginning December 1, 2026, Esri will retire a collection of legacy demographic map layers in ArcGIS Online. The services supporting these layers will be completely shut off by the end of December 2026”, and “Once the supporting services are shut off, the retiring layers will no longer display or function in any maps, applications, dashboards, and other workflows that leverage these layers.”

The sample layers in this article are not among them. Enumerating the retirement group item by item returns 642 items: 319 map services and 323 web maps, and zero feature services. No title matches “home value.” Neither the county layer nor the Median Home Value 2026 web map that Esri’s post links is in the group, and the service behind them — USA_Latest_Esri_Demographics — is categorized General Availability, not Retiring. Saying otherwise would be a false alarm, so: it is not affected.

The general caution still stands, and it stands for a reason worth naming. The retiring set is 323 web maps as well as the services beneath them, and Esri’s own note is that “copies of web maps or applications may still contain a reference to the retired service”. A focus map you built by copying a Living Atlas web map in 2024 is exactly the shape of thing that carries such a reference. As of late September 2026 that is roughly nine weeks of notice.

One trap while you are checking. That demographics service returns owner: esri_premium and, at the same time, access: public with no subscription keyword. Read the item metadata rather than reasoning from the owner name — and do not read public access as a license. Being readable and being licensed for your use case are different questions, and the item’s own license text points at the Esri Master License Agreement for the second one.

What we have not tested

Being straight about the boundary of this article. Every statement above comes from Esri documentation and from probing Esri’s public saved web maps over the REST endpoint. We have shipped no production work using blendMode or featureEffect — searching both of our ArcGIS application codebases for either name returns nothing outside vendored SDK files — so there is no “in our experience” here to offer, and none is implied. No map was rendered in the course of this research. Where the article describes what a client does with a property, it is describing what the shipped code and the reference pages say it does.

Three questions are genuinely open, and they are the ones worth an hour if this pattern is going into something you own. What a persisted feature effect with a null filter actually renders. What the four ArcGIS app products do with these properties, which nothing in their documentation says. And whether the Country Focus sample, twelve specification revisions behind its siblings at 2.25, behaves identically to a map saved today. Each is answerable in a browser in minutes, and none is answerable from a document.

What is settled is the part that changes how you plan. The focus you author in Map Viewer is three properties in a JSON document, not a picture. It is scoped by a rule the Map Viewer help never states. It is not a boundary, however much it looks like one. And on the way to the most ordinary deliverable there is — a printed map — both documented paths either throw it away outright or hand it back to you at screen resolution. That is a good technique with a short, specific list of places it does not go. Knowing the list before you build is the whole difference.

References

• ArcGIS Online — apply blend modes in Map Viewer (the Appearance > Blending control, the 30 modes in six themes, the Compositing family definitions, and that a blend mode changes no data and is saved with the map)
• ArcGIS Online — apply effects in Map Viewer (the Whole layer versus Feature-specific split, the nine whole-layer effects, the nine feature-specific presets, the default filter expression, and the clustering exclusion)
• Web map specification — feature effect object (the three properties, the single where property on its filter, and the twelve layer types that reference it)
• Web map specification — effect object (the array-of-typed-objects shape, the scale-dependent form and its interpolation, and the thirty-five referencing layer types)
• Web map specification — group layer object (the rule that sublayers of a group are blended in isolation from the rest of the map, and the thirty-one valid blend mode values)
• Maps SDK for JavaScript — the blend layer mixin (the nine layer types that support blending in 3D, the Legend exclusion, and the factors that feed a blend result; quoted from the v5.1 reference now served at /latest/, with identifiers and since-versions checked against the shipped 5.0.19 package)
• Maps SDK for JavaScript — the feature effect class (the 2D-only scope, the eleven supported effect functions, the attribute-filter-only persistence rule, and the heatmap and cluster exclusions)
• Maps SDK for JavaScript — the feature effect layer mixin (the fixed composition order of the four presentation properties, and layer versus layer-view inheritance and precedence)
• Maps SDK for JavaScript — the print module (the unsupported blend modes, the group-layer exclusion, the sixteen supported modes on ArcGIS Server 10.9.1 or later, and the client-side image behavior)
• ArcGIS Online — print maps in Map Viewer (the configurations that print as if they were not applied, and the legend, clipping and symbol-rotation consequences of an effect)
• Maps SDK for JavaScript — the group layer class (that the first layer added is always the base layer whatever the order, and the inherited visibility mode that keeps a mask from being switched off on its own in a map built from code)
• Maps SDK for JavaScript — the map view class (that a canvas screenshot captures the rendered geographical elements and excludes overlaid DOM elements, and that it is taken inside the padded area of the view)
• ArcGIS Online — credits for analysis in Map Viewer (the one credit per thousand features charged for Create Buffers, which is how most mask polygons get made)
• ArcGIS Online — understand credits (that most ArcGIS Online work is not metered, and the five-credit charge scoped to printing from custom layout templates)
• ArcGIS Online — user types (that Viewers cannot create, edit or share content, and that Creators can)
• ArcGIS Online — accessibility (the color-contrast guidance and the browser color-filter extension recommendation for checking color vision deficiency)
• Web Content Accessibility Guidelines 2.2 (the normative text of 1.4.1 Use of Color, 1.4.3 Contrast (Minimum) and 1.4.11 Non-text Contrast, each with its exceptions)
• ArcGIS Blog — demographic map layers retiring December 2026 (the December 1, 2026 retirement date, the full shutdown by the end of that month, and the warning about copied maps that still reference a retired service)
• ATS — three ways to narrow a feature layer, and the count you can quote (the from-code comparison of the three levers and the conditions a feature effect has to meet before it will persist into a web map)